[LU-11799] sanity test_270f FAIL: Able to create DoM component size more than LOD limit Created: 17/Dec/18  Updated: 16/Jan/22  Resolved: 16/Jan/22

Status: Closed
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.12.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Sarah Liu Assignee: Mikhail Pershin
Resolution: Cannot Reproduce Votes: 0
Labels: None

Attachments: Text File sanity.test_270f.dmesg.trevis-60vm7.1544773155.log    
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

Did rolling upgrade, after rolling upgrade OSS and MDS from 2.11 EL7.5 to 2.12-RC2 EL7.6 ldiskfs(client remained as 2.11), sanity test_270f failed as below

== sanity test 270f: DoM: maximum DoM stripe size checks ============================================= 07:39:14 (1544773154)
 sanity test_270f: @@@@@@ FAIL: Able to create DoM component size more than LOD limit 
  Trace dump:
  = /usr/lib64/lustre/tests/test-framework.sh:5734:error()
  = /usr/lib64/lustre/tests/sanity.sh:16156:test_270f()
  = /usr/lib64/lustre/tests/test-framework.sh:6010:run_one()
  = /usr/lib64/lustre/tests/test-framework.sh:6049:run_one_logged()
  = /usr/lib64/lustre/tests/test-framework.sh:5896:run_test()
  = /usr/lib64/lustre/tests/sanity.sh:16192:main()


 Comments   
Comment by Andreas Dilger [ 17/Dec/18 ]

I think this is a non-bug, as we changed the MDS code to silently convert the too-large DoM component size to be limited by the lod.*.dom_stripesize limit.

Assigning to Mike to verify, but I think this can be closed as "Not a bug".

Comment by Mikhail Pershin [ 18/Dec/18 ]

yes, this is not a bug, should I make a patch for pre-2.12 clients to don't fail?

Comment by Andreas Dilger [ 19/Dec/18 ]

I don't think we will be patching 2.11, ao it probably is not worthwhile. This test should just be added to the EXCEPT list when running 2.11 interop.

Comment by Minh Diep [ 03/Apr/19 ]

+1 on b2_12: https://testing.whamcloud.com/test_sets/0fb97ed2-552d-11e9-9720-52540065bddc
what's the next step on this failure?

Generated at Sat Feb 10 02:47:02 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.