[LU-14168] e2fsck should avoid moving files into lost+found

• Type: Improvement
• Resolution: Unresolved
• Priority: Major
• Labels: e2fsprogs
• Assignee: WC Triage
• Reporter: Andreas Dilger

Description

When e2fsck finds a directory that is hard-linked between an existing directory and lost+found, it appears to prefer moving the file into lost+found rather than keeping it connected to the original parent directory:

'..' in /lost+found/#471345273 (471345273) is /ROOT/RUNDIRS/2018051500/output (471373040), should be /lost+found (11).
Fix? no
Entry 'tmp249767' in /ROOT/RUNDIRS/2018051500/output (471373040) is a link to directory /lost+found/#471345273 (471345273 fid=[0x200039c0f:0x1d51c:0x0]).
Inode 471345273 ref count is 2, should be 3.  Fix? no
Entry '#471345273' in /lost+found (11) has an incorrect filetype (was 1, should be 2).
Fix? no

It would make more sense for e2fsck to prefer not moving files into lost+found if there is somewhere else that the inode could be attached.

Issue Links

• is related to: LU-4876 LFSCK remove entry from /REMOTE_PARENT_DIR if MDT-object name reside on the same MDT after migration
• is related to: LU-15388 Wrong dotdot FID parameter for osd_add_dot_dotdot()
• is related to: LU-14894 Parallel pass2 support for e2fsck

Comments

[Andreas Dilger]

I think the main obstacle to linking directory inodes back into the original parent directory (based on the inode number stored in ..) is that e2fsck would normally not know the filename. For Lustre filesystems, the correct filename can be found in a number of ways:

• for MDTs with REMOTE_PARENT_DIR as the parent (most common case for MDTs other than MDT0000) the filename is the FID, which is stored in the trusted.lma xattr in the inode
• for MDTs where REMOTE_PARENT_DIR is not the parent, the filename for a particular parent directory FID can normally be found in the trusted.link xattr, unless the file has hundreds of links and trusted.link is full
• for OSTs the parent will normally be object directories under O/<seq>/d*, and the filename is the FID OID (decimal for f_seq=0, hex for all others), and the FID can also be extracted from the trusted.lma xattr

Being able to correctly repair the directory entry in the parent, rather than dumping all files into lost+found would avoid a considerable amount of duplicate work (add entry to lost+found, update .., fix link count, then repair it again later by OI Scrub or LFSCK). The only drawback is that this would be specific to Lustre unless we can implement trusted.link for upstream ext4 (ideally with the same on-disk format using struct link_ea_header and struct link_ea_entry, otherwise with a different xattr name and/or leh_magic).