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-3469 Lustre <p>lod_sync() should be changed to allow flushing the pending OST object destroys so that LFSCK can ensure that the OST state is consistent after pass 1 is completed:</p> <ul class="alternate" type="square"> <li>call local/child OSD dt_sync() first, so that unlink name commit callbacks will be run and schedule all of the OST object destroys</li> <li>OSP dt_sync() will wait until all of the pending object destroys are at least sent to the OSTs (accessing their respective OST objects and removing them from the orphan list). They do not necessarily need to be committed.</li> </ul> LU-3469

OSP dt_sync() operation should flush pending destroys and other updates

Technical task LU-4701 Blocker Resolved Fixed nasf Andreas Dilger Thu, 13 Jun 2013 06:38:26 +0000 Tue, 22 Jul 2014 17:30:56 +0000 Wed, 4 Jun 2014 12:00:21 +0000 Lustre 2.6.0 Lustre 2.6.0 0 6 <p>Alex, any comments on this issue?</p> <p>One proposal is to have LFSCK only do a sync on a specific FID (e.g. the orphan object FID) will cause the pending destroys to be flushed. There is a larger question of whether sync on the LOD in general should cause all the destroys to be flushed, so that users can force file deletions to be flushed to the OSTs and release space. </p> <p>This issue is a fairly rare case of files being deleted that were traversed in the last 15 or so seconds of the phase II namespace scan. At worst this would result in previously-deleted files being linked into lost+found. </p> <p>After discussion with Fan Yong: I would like this bug to be considered for Blocker status.</p> <p>Recently, I hit some test failures for test_18d/test_18e. The root reason is that the async repair operations triggered during first cycle scanning are not executed until orphan handling phase.</p> <p>So we need the dt_sync() for that.</p> <p>Yong, could you point out which specific lines will be calling dt_sync(), please?</p> <p>Alex, the current LFSCK does not call it since osp_sync() is not implemented. But it is easy to add it as the following patch:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">diff --git a/lustre/lfsck/lfsck_layout.c b/lustre/lfsck/lfsck_layout.c index de96726..7be2346 100644 --- a/lustre/lfsck/lfsck_layout.c +++ b/lustre/lfsck/lfsck_layout.c @@ -3435,6 +3435,9 @@ <span class="code-keyword">static</span> <span class="code-object">int</span> lfsck_layout_assistant(void *args) com-&gt;lc_time_last_checkpoint + cfs_time_seconds(LFSCK_CHECKPOINT_INTERVAL); + <span class="code-comment">/* flush all async updating before handling orphan. */</span> + dt_sync(env, lfsck-&gt;li_next); + <span class="code-keyword">while</span> (llmd-&gt;llmd_in_double_scan) { struct lfsck_tgt_descs *ltds = &amp;lfsck-&gt;li_ost_descs; </pre> </div></div> <p>Alex, Fan Yong, is there any reason not to just convert the previous comment into a patch? Is there more work to be done?</p> <p>like said before, osp_sync() is empty yet, I've been working on this.</p> <p>also, at the moment I'm not sure just a single dt_sync() is good enough. failed osp_sync() isn't any different from failed transaction? if we can't complete one phase on a specific OST we shouldn't continue with that OST in this LFSCK run? IOW, we'd prefer to track per-OST status rather than combined one which doesn't let us learn which OSTs are safe to proceed?</p> <p>If osp_sync() is failed to flush all pending destroy to OSTs, and if the LFSCK goes ahead for orphan handling, then the LFSCK may found some OST-object)(s) which parent MDT-object have been destroyed on the MDT(s) by unlink, but the LFSCK cannot be aware of the race unlink, so it will re-create the MDT-object(s), that is unexpected.</p> <p>One possible solution is that, if some osp_sync() failed, then skip orphan handling on related OST(s).</p> <p> <a href="http://review.whamcloud.com/10046" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10046</a> - this patch implements osp_sync() which is synchronous. give the discussion above I tend to think it'd be better to call into all OSPs/OSDs directly from LFSCK. in the long term, something like an empty (or almost empty <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/> async transactions with commit callbacks registered would serve better being concurrent.</p> <p>Alex, Fan Yong, what is needed next for this patch? Are further changes needed in the LFSCK code to start using this new functionality?</p> <p>Generally, the patch looks good, but we still cannot land the patch because of Maloo test failure.</p> <p>Assigned to Fan Yong as he has updated the patch</p> <p>Landed for 2.6</p> Blocker LU-3336 Related LU-5387 Development Rank 1|hzvt9z: Rank (Obsolete) 8679