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-16336 Lustre <p>In <a href="https://jira.whamcloud.com/browse/LU-16159" title="remove update logs after recovery abort" class="issue-link" data-issue-key="LU-16159">LU-16159</a>, the update logs are canceled upon recovery, which will cause inconsistencies in the filesystem. LFSCK should be able to fix these inconsistencies.</p> <p>This is visible in tests like replay-single test_70b that sometimes leave an undeletable directory behind after test completion (<a href="https://jira.whamcloud.com/browse/LU-10616" title="replay-single test_70b fails with &#39;rundbench load on &lt;hostname(s)&gt; failed!&#39; " class="issue-link" data-issue-key="LU-10616">LU-10616</a>). There are various workarounds (e.g. <a href="https://jira.whamcloud.com/browse/LU-16335" title="&quot;lfs rm_entry&quot; failed to remove broken directories" class="issue-link" data-issue-key="LU-16335"><del>LU-16335</del></a> to use "<tt>lfs rm_entry</tt>" to unlink the directory from the namespace, or EX-6692 to reformat the filesystem), but it would be much better to have LFSCK fix these directories and/or allow them to actually be unlinked from the filesystem.</p> LU-16336

LFSCK should fix inconsistencies caused by recovery abort

Bug Major Open Unresolved Lai Siyao Lai Siyao Wed, 23 Nov 2022 07:10:01 +0000 Thu, 30 Mar 2023 09:16:01 +0000 Lustre 2.16.0 0 5 <p>We've seen that the <tt>rm_entry</tt> workaround to "hide" the bad entry is only temporary, and running LFSCK on the filesystem will restore the broken entry back to <tt>.lustre/lost+found/&lt;fsname&gt;-MDT0000</tt> where it will again be undeletable.</p> <p>We either need to be able to delete such a directory with missing stripes using "<tt>rmdir</tt>" if we are sure the MDT is available but the the stripe is missing, or have LFSCK fix the missing stripe in the directory so that it can be removed normally.</p> <p>Is it possible that patch <a href="https://review.whamcloud.com/47385" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/47385</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-14470" title="striped directory layout mismatch after failover" class="issue-link" data-issue-key="LU-14470">LU-14470</a> dne: striped mkdir replay by request</tt>" will avoid such recovery failures by allowing the client to recover the broken directory even when the MDT recovery is aborted?</p> <p>Yes, <a href="https://jira.whamcloud.com/browse/LU-14470" title="striped directory layout mismatch after failover" class="issue-link" data-issue-key="LU-14470">LU-14470</a> can help create failure, and beyond that, we need to consider other distributed transaction replay as well, e.g. migration and restripe. Besides, if client replay is aborted as well, it may still leave dangling name entries.</p> <p>I didn't test yet, IMHO LFSCK won't simply move dangling name entries to lost+found.</p> Related LU-14470 LU-10616 LU-15624 LU-16065 LU-16159 LU-16335 Development Rank 1|i036db: Rank (Obsolete) 9223372036854775807 Severity