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-3871 Lustre <p>It can be easily reproduced by:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">sh llmount.sh .... sh llmountcleanup.sh .... e2fsck -fn $ost_dev </pre> </div></div> <p>The e2fsck shows:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">e2fsck 1.42.7.wc1 (12-Apr-2013) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Inode 90 ref count is 1, should be 2. Fix? no Inode 94 ref count is 1, should be 2. Fix? no Inode 105 ref count is 1, should be 2. Fix? no Inode 107 ref count is 1, should be 2. Fix? no Pass 5: Checking group summary information lustre-OST0000: ********** WARNING: Filesystem still has errors ********** lustre-OST0000: 293/50016 files (0.7% non-contiguous), 9608/50000 blocks </pre> </div></div> <p>I tracked the problem and looks it's introduced by commit: e0702769f267dd009a6287bbc9da2760079a101d (<a href="https://jira.whamcloud.com/browse/LU-3126" title="conf-sanity test_41b: fld_server_lookup()) ASSERTION( fld-&gt;lsf_control_exp ) failed" class="issue-link" data-issue-key="LU-3126"><del>LU-3126</del></a> osd: remove fld lookup during configuration)</p> LU-3871

e2fsck reports inode reference count error

Bug Critical Resolved Fixed Di Wang Niu Yawei Mon, 2 Sep 2013 07:45:29 +0000 Mon, 7 Oct 2013 14:25:31 +0000 Mon, 30 Sep 2013 23:31:08 +0000 Lustre 2.5.0 Lustre 2.5.0 0 6 <p>Di, could you take a look? Thanks.</p> <p>The changes in fid_is_on_ost() is highly suspicious (e0702769f267dd009a6287bbc9da2760079a101d):</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">--- a/lustre/osd-ldiskfs/osd_oi.c +++ b/lustre/osd-ldiskfs/osd_oi.c @@ -470,8 +470,6 @@ <span class="code-keyword">static</span> <span class="code-object">int</span> osd_oi_iam_lookup(struct osd_thread_info *oti, <span class="code-object">int</span> fid_is_on_ost(struct osd_thread_info *info, struct osd_device *osd, <span class="code-keyword">const</span> struct lu_fid *fid, <span class="code-keyword">enum</span> oi_check_flags flags) { - struct lu_seq_range *range = &amp;info-&gt;oti_seq_range; - <span class="code-object">int</span> rc; ENTRY; <span class="code-keyword">if</span> (flags &amp; OI_KNOWN_ON_OST) @@ -487,17 +485,7 @@ <span class="code-object">int</span> fid_is_on_ost(struct osd_thread_info *info, struct osd_device *osd, <span class="code-keyword">if</span> (!(flags &amp; OI_CHECK_FLD)) RETURN(0); - rc = osd_fld_lookup(info-&gt;oti_env, osd, fid, range); - <span class="code-keyword">if</span> (rc != 0) { - CERROR(<span class="code-quote">"%s: Can not lookup fld <span class="code-keyword">for</span> "</span>DFID<span class="code-quote">"\n"</span>, - osd_name(osd), PFID(fid)); - RETURN(rc); - } - - CDEBUG(D_INFO, <span class="code-quote">"fid "</span>DFID<span class="code-quote">" range "</span>DRANGE<span class="code-quote">"\n"</span>, PFID(fid), - PRANGE(range)); - - <span class="code-keyword">if</span> (fld_range_is_ost(range)) + <span class="code-keyword">if</span> (osd-&gt;od_is_ost) RETURN(1); RETURN(0); </pre> </div></div> <p>Which definitely changed the behaviour when OI_CHECK_FLD is present (after the change, fid_is_on_ost() will always return 1 on the ost device)</p> <p>And I found the following code looks confusing to me:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">#define LU_SEQ_RANGE_MDT 0x0 #define LU_SEQ_RANGE_OST 0x1 #define LU_SEQ_RANGE_ANY 0x3 #define LU_SEQ_RANGE_MASK 0x3 </pre> </div></div> <p>What does LU_SEQ_RANGE_ANY mean? It's a combination of RANGE_MDT and RANGE_OST or it's another type of RANGE?</p> <p>I pushed patch <a href="http://review.whamcloud.com/#/c/7527/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7527/</a> . I thought the problem is in the osd_oi_insert, and it seems a lot special FIDs is inserted into IAM, is this on purpose? or bug? related with OI scrub? Fan Yong, could you please have a look?</p> <p>Inserting local object into OI (oi.16.xxx) is expected. They can be easily distinguished from other normal FIDs. They are either IGIFs or local FIDs.</p> <p>Niu, which inodes are the ones reported by e2fsck (90, 94, 105, 107)? Are these OST objects, directories, other?</p> <p>I believe they are special objects on OST, such as named llog, global quota files, etc. Di has posted a patch for this (<a href="http://review.whamcloud.com/#/c/7527/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7527/</a>), though it needs be updated.</p> <p>Landed for 2.5.0</p> Duplicate LU-3996 Development Rank 1|hzvzt3: Rank (Obsolete) 10043 Severity