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-14521 Lustre <p>As noted on <a href="https://review.whamcloud.com/#/c/41906/2/src/lpurge.c@765:" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/41906/2/src/lpurge.c@765:</a></p> <p>(suggestion) Rather than opening a volatile file just to delete the mirror, it might be useful to have some "magic" fd that just means "delete the mirror" that can be handled directly by the MDS? That would avoid at least 2 RPCs per split.</p> LU-14521

delete FLR mirrors without volatile files

Bug Minor Resolved Fixed Zhenyu Xu John Hammond bjhpflr Sat, 13 Mar 2021 15:10:36 +0000 Thu, 24 Jun 2021 15:24:56 +0000 Sun, 11 Apr 2021 12:59:07 +0000 Lustre 2.15.0 0 7 <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=bobijam" class="user-hover" rel="bobijam">bobijam</a> could you look at this? We want a way to do <tt>lfs mirror split <del>d</tt> without a volatile file. Can the <tt></del>-component-del</tt> code be adapeted? It would be good to have a mini-design before we implement.</p> <p>My thought about mirror deleting is that we still use the mdd_xattr_split(), but in the case of mirror deleting, we'd create a new interface unto LOD layer, telling lod to delete all objects in the to-be-deleted mirror. Also we'd take care of mirror-deleting case in mdt_close_handle_layouts(), we don't need to create the temporary file object in the mirror-deleting case.</p> <p>Seems fine to me.</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=bzzz" class="user-hover" rel="bzzz">bzzz</a>, <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger" class="user-hover" rel="adilger">adilger</a> any ideas or comments?</p> <p>No objection from me as long as we don't duplicate too much code.</p> <p>Looking at <tt>mdd_xattr_split()</tt> it looks like it will return <tt>-EPERM</tt> if you try to "split" the layout into the same FID as the source. One option would be to use this behavior to do the "delete the mirror directly" case, so that userspace can determine whether the server deleted the mirror (i.e. no error returned), or if it needs to do that itself via volatile file (i.e. <tt>-EPERM</tt> returned). On the minus side, if users specify the source file as the target file for the split they may be surprised at this behavior, but this could be checked in <tt>lfs</tt> rather than on the MDS?</p> <p>Bobi Jam (bobijam@hotmail.com) uploaded a new patch: <a href="https://review.whamcloud.com/42116" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/42116</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-14521" title="delete FLR mirrors without volatile files" class="issue-link" data-issue-key="LU-14521"><del>LU-14521</del></a> flr: delete mirror without volatile file<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 496231e86aa4b14c4709778589ba92026e67d26c</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/42116/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/42116/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-14521" title="delete FLR mirrors without volatile files" class="issue-link" data-issue-key="LU-14521"><del>LU-14521</del></a> flr: delete mirror without volatile file<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: b2d73351e64677cb8ff650d92a8744634f73e0fd</p> <p>Landed for 2.15</p> Development Rank 1|i01pen: Rank (Obsolete) 9223372036854775807 Severity