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-7231 Lustre <p>In current DNE implementation, when creating a striped directory. In execution phase, the master MDT will only pack the remote updates inside the RPC, and these updates will not be executed until top_trans_stop() sends these updates to remote MDT. If these remote updates fails, for example ENOSPC for writing update log, but local updates succeeds, then we need rollback those local updates (or do better job during declaration?), otherwise the namespace space might be inconsistency. </p> <p>This can be reproduced by the test case in <a href="http://review.whamcloud.com/16677" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16677</a></p> LU-7231

ENOSPC on remote MDT might create a in-consistent striped directory

Bug Minor Resolved Duplicate Di Wang Di Wang Wed, 30 Sep 2015 01:59:55 +0000 Mon, 26 Oct 2015 18:43:59 +0000 Mon, 26 Oct 2015 18:43:45 +0000 Lustre 2.8.0 0 5 <p>instead we should reserve space, IMO. i.e. have grants for metadata.</p> <p>I agree caching the status of the remote target and had it checked in the declare phase might be the right way to go. But for 2.8, is there better temporary way to fix it, instead of using this "lfs rm_entry" to delete this corrupted striped dir afterwards. (Btw: please check the patch <a href="http://review.whamcloud.com/16677" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16677</a>, thanks!).</p> <p>it's probably not that trivial to rollback everything. say, a record in changelog. also, having a failure on a one target doesn't mean all the targets failed, right? then we'd need to rollback those too.</p> <p>How hard would it be in the error handler (for -ENOSPC, or whatever else) to unlink the local name entry on the master and do a best effort to remove the remote directories? No huge loss if the remote entries are leaked, but it doesn't make sense to return success creating a striped directory that isn't actually usable.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>How hard would it be in the error handler (for -ENOSPC, or whatever else) to unlink the local name entry on the master and do a best effort to remove the remote directories? </pre> </div></div> <p>Oh, lfs mkdir will return error for this case, because the remote transaction will fail, and MDD can still track this error and reply it to client. But it will leave a corrupt striped directory on the server side, if we do not do anything there. Right now, the solution is that the user can delete this striped directory by himself with lfs rm_entry. See patch <a href="http://review.whamcloud.com/16677" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16677</a>. </p> <p>Why not try to unlink the name on the master MDT and the remote slaves if there is an error? Surely that is better than waiting for the client to do it? Trying to clean up and failing is no worse than not trying at all and leaving a broken directory behind.</p> <p>This will be fixed by <a href="https://jira.whamcloud.com/browse/LU-7230" title="memory leak in sanityn.sh 90 &amp; 91" class="issue-link" data-issue-key="LU-7230"><del>LU-7230</del></a>. </p> Related LU-7230 Development Rank 1|hzxp33: Rank (Obsolete) 9223372036854775807 Severity