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-11577 Lustre <p>using the current e2fsprogs-1.44.3.wc1</p> <p>we are getting lots of</p> <p>Multiply-claimed block(s) in inode 486666: 986392108 986392259<br/> Multiply-claimed block(s) in inode 486672: 986533901<br/> Multiply-claimed block(s) in inode 486674: 986534585</p> <p>Should we let fsck run and clean these up?</p> LU-11577

fsck Multiply-claimed block(s)

Bug Critical Resolved Fixed Andreas Dilger Mahmoud Hanafi Fri, 26 Oct 2018 23:11:59 +0000 Wed, 21 Sep 2022 15:59:12 +0000 Sat, 27 Oct 2018 03:46:20 +0000 0 7 <p>Three Sev 1s within one day must be a record! <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/> Andreas has been in transit today too and will no doubt give a definitive answer when he is able to, but my guess is that it is ok to let lfsck run and move these files to the lost and found where you can then work out what can be salvaged.</p> <p>Yes it has been a nightmare.</p> <p> </p> <p>The fsck is just taking a very very long time and is very slow.</p> <p> is it safe to run with</p> <p>-E clone=zero shared=lost+found</p> <p>or</p> <p>shared=delete.</p> <p>There should not be this many shared blocks.</p> <p>looks like a single inode with the majoriy of the issues</p> <p>Inode: 3821842 Type: regular Mode: 0700 Flags: 0x1802f<br/> Generation: 67584 Version: 0x00b70790<br/> User: 0 Group: 22176 Size: 4299265028096<br/> File ACL: 0<br/> Links: 23506 Blockcount: 251949840<br/> Fragment: Address: 0 Number: 0 Size: 0<br/> ctime: 0x6e0f0f87 &#8211; Thu Jul 6 00:19:35 2028<br/> atime: 0x2e2281b6 &#8211; Tue Jul 12 04:42:46 1994<br/> mtime: 0x00000000 &#8211; Wed Dec 31 16:00:00 1969<br/> Size of extra inode fields: 0<br/> BLOCKS:</p> <p>attaching fsck <span class="nobr"><a href="https://jira.whamcloud.com/secure/attachment/31347/31347_fsck.out" title="fsck.out attached to LU-11577">fsck.out^{<img class="rendericon" src="https://jira.whamcloud.com/images/icons/link_attachment_7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>output</p> <p>The shared blocks phase can be very long, and often does not produce useful results, especially if there is random filesystem corruption that caused it (some random 32-bit data will always be a valid block number for filesystems over 16TB in size). The above inode looks like total garbage - random blocks and size, timestamps, etc.</p> <p>It doesn't look like you have that big a problem, so if it has already finished there is no need to do anything else immediately. If it is still running then you might consider to restart e2fsck with the "-E" options above. Either "shared=lost+found" or "shared=delete" is probably OK (obviously the filesysyem metadata won't be deleted). </p> <p>Alternately, you could use <tt>debugfs -w</tt> to mount the filesystem and zero out this inode via "<tt>mi &lt;3821842&gt;</tt>" and set all of the fields to zero, which should avoid e2fsck doing anything with it except mark it deleted.</p> <p>Thank the mi &lt;&gt; worked.</p> <p>You may close this case.</p> <p> </p> <p> </p> <p>Yes, you could try to delete the object, but might trigger the mounted filesystem to go read-only as it detects filesystem metadata blocks being freed. Using debugfs to just zero out the inode avoids it from actually trying to free the blocks. Note that you can use "<tt>debugfs -w -R 'clri &lt;3821842&gt;' /dev/mapper/nbp10_1-OST30</tt>" should do the same thing as running "<tt>mi</tt>" interactively - zero out the offending inode without trying to free the blocks. </p> <p>In any case, you still need to run a full e2fsck after cleaning up the inode. Directly deleting it will mark the "shared" blocks as freed in the allocation bitmaps, and without the post-delete e2fsck it will lead to further corruption as those blocks are reallocated. Zeroing it out with debugfs will likely mean less metadata to repair, but there may still be errors to fix.</p> Related LU-16171 Development Rank 1|i0057z: Rank (Obsolete) 9223372036854775807 Severity