Affects Version/s: Lustre 2.10.0
Fix Version/s: None
sanity test_184d fails when there is a default composite layout set on $DIR with:
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