Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Lustre 2.10.0
-
3
-
9223372036854775807
Description
sanity test_184d fails when there is a default composite layout set on $DIR with:
sanity test_184d: @@@@@@ FAIL: lovea -E 2097152 -c 1 -S 1048576 -i 0 -E -1 -c -1 -S 1048576 -i -1 != -E 2097152 -c 1 -S 1048576 -i 0 -E -1 -c 6 -S 1048576 -i 1
More specifically, when you set a composite layout on $DIR and run sanity.sh test 184d will fail when the number of stripes set on a component is -1.
Here’s essentially what test 184a and why it fails when a composite file layout is set on mount point:
1. touch a file called swapfile1. The last component of the file is uninstantiated and you will see lcme_flags = 0 and lmm_stripe_count = -1 for the last component which matches the composite file layout on the parent dir.
2. create another file with “./openfile -f O_CREAT:O_LOV_DELAY_CREATE /lustre/scratch/swapfile2”
3. now swap the layouts with “lfs swap_layouts /lustre/scratch/swapfile1 /lustre/scratch/swapfile2”
4. The swap works, but the last component of the swapped file, swapfile2, is now instantiated; we see lcme_flags =init and lmm_stripe_count = 6 for the last component of swapfile2.
So, sanity test 184a fails because of the differences in the lmm_stripe_count values; “-1” versus “6”.
Bobi Jam explained this as a “… current PFL swap limitation (initializing all objects before getting the group lock), so that after swap, those un-initialized component got initialized.”
Andreas Dilger commented: My preference would be to avoid instantiating the layout of files during swap, but there is a bug with doing a group lock on uninstantiated components, and the workaround is to force all components to be instantiated.
Logs for one of these failures is at
https://testing.hpdd.intel.com/test_sets/4db252a4-5ba1-11e7-8a1b-5254006e85c2
