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-3335 Lustre <p>This ticket is related to running the existing OI Scrub checking for OST OSD devices. This includes</p> <ul class="alternate" type="square"> <li>running the object iterator (should already work)</li> <li>rebuilding the OI (<tt>O/$seq/d*/$oid</tt> for OST objects</li> <li>rebuilding the <tt>O/$seq/LAST_ID</tt> file if incorrect (<a href="https://jira.whamcloud.com/browse/LU-14" title="live replacement of OST" class="issue-link" data-issue-key="LU-14"><del>LU-14</del></a>)</li> </ul> LU-3335

LFSCK II: MDT-OST OST local consistency checking

New Feature Critical Resolved Fixed nasf Andreas Dilger LFSCK Tue, 14 May 2013 19:37:37 +0000 Mon, 19 Jul 2021 22:29:03 +0000 Mon, 23 Sep 2013 18:17:28 +0000 Lustre 2.5.0 Lustre 2.5.0 Lustre 2.6.0 Wed, 31 Jul 2013 00:00:00 +0000 0 5 <p>in the past I asked few times that OI scrub should be independent from specific OI format whether it's oi.* files or /O hierarchy. the logic of OI scrubber should just use osd_oi_lookup(), osd_oi_delete() and osd_oi_insert() and leave osd_oi_*() functions to decide which mapping to use for a specific object.</p> <p>Sure, the <em>users</em> of OI Scrub will just iterate over the inodes and get the object FIDs from LMA or filter_fid (in case of upgraded filesystems. However, if OST objects are located in <tt>lost+found</tt> due to filesystem corruption, then they need to be moved back to <tt>/O/$seq/d*/$oid</tt> (i.e. restored to the "OI" for the OST). This is currently handled by a separate <tt>ll_recover_lost_found_objs</tt> tool, but it would be better to avoid the need to mount and run this separately on the OST.</p> <p>hmm, I'm not aware of any users of OI Scrub - it's all internal to OSD ?<br/> at which point you want to update LAST_ID? I guess this can't be done any time, OFD might overwrite it immediately?</p> <p>By "users of OI Scrub" I mean "users of the object iterator".</p> <p>I also don't think it is harmful to update LAST_ID under lock, if this is done with proper locking of the LAST_ID object. Since this is now just a normal FID, we should be able to use the object lock to serialize access?</p> <p>The patches list:</p> <p><a href="http://review.whamcloud.com/#/c/6697/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6697/</a><br/> <a href="http://review.whamcloud.com/#/c/6669/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6669/</a><br/> <a href="http://review.whamcloud.com/#/c/6698/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6698/</a><br/> <a href="http://review.whamcloud.com/#/c/6857/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6857/</a><br/> <a href="http://review.whamcloud.com/#/c/7143/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7143/</a><br/> <a href="http://review.whamcloud.com/#/c/7144/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7144/</a><br/> <a href="http://review.whamcloud.com/#/c/7145/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7145/</a></p> <p>OI table based scanning to repair the inconsistency of inode without LMA (or dummy OI mapping items) will be an time-consuming work. Just like find out orphan OST-objects for LFSCK phase II, we can consider to do that in later release. Instead, I made another relative simple patch to resolve part of the issues: only the used/accessed objects will be repaired by the RPC service threads.</p> <p><a href="http://review.whamcloud.com/#/c/6899/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6899/</a></p> <p>Andreas, how do you think?</p> <p>Follow on work for 2.6 is being tracked under <a href="https://jira.whamcloud.com/browse/LU-3995" title="CLONE - LFSCK II: MDT-OST OST local consistency checking" class="issue-link" data-issue-key="LU-3995"><del>LU-3995</del></a>. Any additional patches for this work should be linked to <a href="https://jira.whamcloud.com/browse/LU-3995" title="CLONE - LFSCK II: MDT-OST OST local consistency checking" class="issue-link" data-issue-key="LU-3995"><del>LU-3995</del></a>. Closing this ticket as 2.5 patches have landed.</p> Blocker LU-1267 Duplicate LU-3995 Related LU-14864 LU-4829 LU-3588 Development Epic layout Rank 1|hzvqxz: Rank (Obsolete) 8251 Story Points 89.0