https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-14168 Lustre <p>When e2fsck finds a directory that is hard-linked between an existing directory and lost+found, it appears to prefer moving the file into <tt>lost+found</tt> rather than keeping it connected to the original parent directory:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>'..' 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 </pre> </div></div> <p>It would make more sense for <tt>e2fsck</tt> to prefer <b>not</b> moving files into <tt>lost+found</tt> if there is somewhere else that the inode could be attached.</p> LU-14168

e2fsck should avoid moving files into lost+found

Improvement Major Open Unresolved WC Triage Andreas Dilger e2fsprogs Tue, 1 Dec 2020 23:01:16 +0000 Mon, 31 Jan 2022 23:33:37 +0000 0 2 <p>I think the main obstacle to linking directory inodes back into the original parent directory (based on the inode number stored in <tt>..</tt>) is that e2fsck would normally not know the filename. For Lustre filesystems, the correct filename can be found in a number of ways:</p> <ul class="alternate" type="square"> <li>for MDTs with <tt>REMOTE_PARENT_DIR</tt> as the parent (most common case for MDTs other than MDT0000) the filename is the FID, which is stored in the <tt>trusted.lma</tt> xattr in the inode</li> <li>for MDTs where <tt>REMOTE_PARENT_DIR</tt> is <b>not</b> the parent, the filename for a particular parent directory FID can normally be found in the <tt>trusted.link</tt> xattr, unless the file has hundreds of links and <tt>trusted.link</tt> is full</li> <li>for OSTs the parent will normally be object directories under <tt>O/&lt;seq&gt;/d&#42;</tt>, and the filename is the FID OID (decimal for <tt>f_seq=0</tt>, hex for all others), and the FID can also be extracted from the <tt>trusted.lma</tt> xattr</li> </ul> <p>Being able to correctly repair the directory entry in the parent, rather than dumping all files into <tt>lost+found</tt> would avoid a considerable amount of duplicate work (add entry to <tt>lost+found</tt>, update <tt>..</tt>, 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 <tt>trusted.link</tt> for upstream ext4 (ideally with the same on-disk format using <tt>struct link_ea_header</tt> and <tt>struct link_ea_entry</tt>, otherwise with a different xattr name and/or <tt>leh_magic</tt>).</p> Related LU-4876 LU-15388 LU-14894 Development Rank 1|i01g5z: Rank (Obsolete) 9223372036854775807