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-3569 Lustre <p>Currently, the callers for ostid_to_fid() always use "0" as the "ost_idx" parameter. There are potential issues for that, and may cause FID inconsistency as to crash the system.</p> LU-3569

Use real OST index as ostid_to_fid() parameter instead of always "0"

Bug Critical Resolved Fixed nasf nasf Tue, 9 Jul 2013 06:47:47 +0000 Thu, 25 Jun 2020 02:58:58 +0000 Thu, 10 Dec 2015 18:17:52 +0000 Lustre 2.5.0 Lustre 2.6.0 Lustre 2.8.0 0 7 <p>Hmm, currently, we only use loi_index to locate OST for object with IDIF, so I do not think using "0" can cause potential problem here, unless I miss sth?</p> <p>The problem is that LFSCK will begin storing OST object FIDs in the LMA. If it is storing IDIF FIDs in the LMA with OST index 0, this will be confusing in the future. I would prefer to use a consistent FID when accessing the OST objects so that the code does not have to have as many special cases in it.</p> <p>I see. Ok, then I will work on it. Actually, I tried this before but blocked by some quota issue. Actually I more concerned about the compatiblity issue between old MDT and new OST, if the old MDT use some old IDIF to track some sth. I will check.</p> <p>Wang Di (di.wang@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/7053" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7053</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-3569" title="Use real OST index as ostid_to_fid() parameter instead of always &quot;0&quot;" class="issue-link" data-issue-key="LU-3569"><del>LU-3569</del></a> ofd: packing ost_idx in IDIF<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 0e45c385508fc4377f07595d281911310fce3f29</p> <p>I see that we are already storing the "index == 0" FID into the OST objects with the current master:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># debugfs /dev/vg_sookie/lvost2 debugfs 1.42.7.wc2 (12-Apr-2013) debugfs: stats Filesystem volume name: testfs-OST0001 : : debugfs: stat O/0/d0/1856 Inode: 172 Type: regular Mode: 0666 Flags: 0x80000 : : Extended attributes stored in inode body: lma = "08 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 40 07 00 00 00 00 00 00 " (24) lma: fid=[0x100000000:0x740:0x0] compat=8 incompat=0 fid = "00 04 00 00 02 00 00 00 f8 75 00 00 00 00 00 00 " (16) fid: parent=[0x200000400:0x75f8:0x0] stripe=0 </pre> </div></div> <p>So this is always storing FID_SEQ_IDIF = 0x100000000 into the on-disk OST object LMA, instead of (FID_SEQ_NORMAL + ost_idx &lt;&lt; 16) = 0x100010000 in this case. If this has been around since 2.4.x days then I guess LFSCK will have to fix it up either way and there is no requirement to fix it immediately, but if it is new in 2.5 then I'd prefer that this be fixed before 2.5.0.</p> <p>Oh, unfortunately, we always store FID_SEQ_IDIF(without ost index) for all of OST objects since 2.4.0. So LFSCK have to fix it. Nasf? </p> <p>I am thinking whether we will have the requirement to change OST-index in the future. If we have, then storing OST-index inside the IDIF will be trouble. Because for normal FID, OST-index is meaningless, the client can get the OST-index by checking FLD with the given FID. So as long as we can adjust the FLD correctly, then changing OST-index without breaking the system is easy.</p> <p>Currently, because all the IDIF use 0-index, the OI scrub does not care about the OST-index. But if the up layer change the IDIF logic, means both LOD and OFD use the real OST-index, then OI scrub needs to the OST-index to rebuild the LMA and the /O tree. And before such conversion is completed, the system is un-accessable, it is not like OI scrub for MDT file-level backup/restore. Under the later one case, the system is still accessible during the OI scrub rebuilding the OI files. I am not sure whether OI scrub or the OSD should know the 'index' information or not.</p> <p>Even if we don't store the OST index into the on-disk LMA FID, we need to fix a couple of bugs in the ll_lost_found_objs. </p> <p>Looks like I am mistaken. I thought that it was a bug for ll_recover_lost_found_objs checking fid_seq_is_idif() and creating the object path LPX64, since this would move objects to "O/0x0/d*" instead of "O/0/d*". However, I didn't notice until now that the old code is actually using LPX64i instead of LPX64, and LPX64i prints zero as "0" instead of "0x0".</p> <p>Even so, I cleaned up the code a bit to consolidate where the seq_name is being generated into one place, and IDIF objects now use LPU64 for the seq_name to make the code more clear.</p> <p><a href="http://review.whamcloud.com/7880" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7880</a></p> <p>Andreas, is there anything needed for this ticket?</p> <p>Lai, I'd be grateful if you could revive my <a href="http://review.whamcloud.com/7880" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7880</a> patch to fix ll_recover_lost_found_objs, or possibly better is to make a different patch to delete ll_recover_lost_found_objs.c entirely because LFSCK should handle that now (sanity-scrub test_14 tests this).</p> <p>As per discussion on the triage call, let's just delete the tool for 2.8</p> <p>Lai Siyao (lai.siyao@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/16477" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16477</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-3569" title="Use real OST index as ostid_to_fid() parameter instead of always &quot;0&quot;" class="issue-link" data-issue-key="LU-3569"><del>LU-3569</del></a> utils: remove ll_recover_lost_found_obj<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: ef14f2f062ee31302d55a0a29ecee94233f47aa8</p> <p>Fan Yong</p> <p>We have been discussing this issue on the triage call and it looks like an fsck issue. Could you please look at the latest feedback in the patch and see what needs to be done?</p> <p>Thanks</p> <p>Peter</p> <p>Peter, I have refreshed the patch <a href="http://review.whamcloud.com/#/c/16477/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/16477/</a></p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/16477/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/16477/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-3569" title="Use real OST index as ostid_to_fid() parameter instead of always &quot;0&quot;" class="issue-link" data-issue-key="LU-3569"><del>LU-3569</del></a> utils: remove ll_recover_lost_found_obj<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 8f810496b9b13b79018b6889939a6de6e19ddddd</p> <p>Last patch has landed for 2.8.</p> Related LU-7585 LU-8898 LU-4414 LU-4232 LU-4414 Development Rank 1|hzvut3: Rank (Obsolete) 8988 Severity