Details
-
Bug
-
Resolution: Fixed
-
Major
-
Lustre 2.4.0, Lustre 2.4.1
-
None
-
Lustre 2.4.1 RHEL6 2.6.32-358.18.1.el6_lustre.x86_64
-
4
-
11777
Description
"lfs_migrate -y" aborts with this error
cannot swap layouts between <filename> and a volatile file (Operation not permitted)
This seems to happen for all files. The lfs_migrate operation aborts on the first file.
Attachments
Issue Links
Activity
My patch at http://review.whamcloud.com/8737 seems to address the original need (allow legitimate IGIFs, handle root special-case, ...) for this ticket now, only have to answer reviewers comments.
Patch http://review.whamcloud.com/8616 was cherry-picked to Lustre b2_5 branch.
I wonder if the -EPERM error seen on non-IGIF files is due to some file ownership problem like LU-3826 or similar?
if ((attr1->la_uid != attr2->la_uid) ||
(attr1->la_gid != attr2->la_gid))
RETURN(-EPERM);
This will fail if lfs_migrate is not creating the file with the same ownership as the original file? If lfs_migrate is running as root, then it should be able to fchown() the file after it is created. The actual permissions don't matter, because the temporary file will be deleted, but this is proof that the caller of the migrate has permission to do this swap.
Patch to allow layout swap for IGIF file is at http://review.whamcloud.com/8737.
Humm thanks, I understand I better had to read LU-4392 sub-task and learn more about LFSCK behavior than to ask, sorry !!
So now, do we really need to detect such files with a wrongly assigned IGIF by LFSCK (to be fixed in LU-4392 sub-task) ?? Because if not, fix for this ticket's original issue could simply be to add fid_is_igif() test for both files having their layouts swapped, in mdd_layout_swap_allowed().
I may miss some special cases about files with IGIF here since you wrote about "internal system files by using their (internal) IGIF FIDs" ??…
I will also work on the MDT volatile object leak upon layouts swap failure, may be as part as a new ticket.
I created the IGIF files under 1.8 and upgraded to 2.x. You could also get the same effect by mounting a 2.4 MDT as ldiskfs, deleting the "lma" xattr, then rounding and running LFSCK to fix the OI.
Sorry to be late, but I am back on this one.
Andreas, sorry to ask but can you explain me how the files created in MDT root-directory have an IGIF assigned ??
I also confirm that as part of LU-3834, and fault-injection during layouts-swap to verify patch behavior, I reproduce the volatile object leak (inode links number is 1 and e2fsck detects "Unattached inode") on MDT. In my case, and for one layouts-swap forced error, I see one orphan inode with ".^L^S^T^R:VOLATILE"/LUSTRE_VOLATILE_HDR linkEA but also one with "i_am_nobody", did you also find this ?
But anyway, this clearly indicate that there is something to address and fix upon layouts-swap error.
Uploaded a patch to correctly handle "lfs migrate" failure in lfs_migrate and do fallback to rsync copy+rename:
http://review.whamcloud.com/8616
This is not a complete solution to the problem here, but is useful in any case.
Bruno, yes after the migration failure the original file is still accessible. Ideally, if the MDD could verify if the object is in the namespace then that would be a good way to know if it can be migrated or not. I think allowing to migrate IGIF FIDs is a potential problem, but not worse than other issues a client might have, so that would be a solution for 2.6 if no others are available.
Andreas,
After the failure, is the original file still accessible ?
Also, since it appears the main problem for this ticket is that trying "lfs migrate" on 1.8 files with IGIF fids will fail and leak volatile objects on MDT, why not 1st change test in mdd_layout_swap_allowed() by adding/allowing also fid_is_igif() files ? Then we will address the special cases of system/ROOT files and the failure/recovery.
Or do you still think all cases must be handled in "lfs migrate" by switching to rsync if not a system/ROOT file, and the leak to be addressed separately ?
But finally may be it is related to LU-3834, after my recent discovery there that the layouts swap-back upon failure may not work as expected!
I have also observed this on a filesystem created with 2.1.x and migrated to 2.4.2.
Exactly the same error message but this happens only with some directories.
Some directories lfs_migrate'd perfectly.