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).
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:
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).