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-1488 Lustre <p>When running 2.1.2 servers with RHEL5/1.8.8 clients, Servers are RHEL6 - seeing this error quite a bit.Test is recovery-scale, but error also observed with other tests. </p> <p>un 6 09:50:44 ehyperion354 Lustre: Server lustre-MDT0000_UUID version (2.1.1.0) is much newer than client version (1.8.8)<br/> Jun 6 09:50:44 ehyperion354 LustreError: 25302:0:(namei.c:256:ll_mdc_blocking_ast()) ### data mismatch with ino 144115305952584894/0 (ffff8101b4b8e9a0) ns: lustre-MDT0000-mdc-ffff81021762a000 lock: ffff810160e1f400/0x793342fb2430adf9 lrc: 3/0,0 mode: PR/PR res: 8589941618/9406 bits 0x1 rrc: 2 type: IBT flags: 0x2002c90 remote: 0xe77c1b87ad8301fe expref: -99 pid: 25116 timeout: 0<br/> Jun 6 09:50:44 ehyperion354 LustreError: 25116:0:(mdc_locks.c:653:mdc_enqueue()) ldlm_cli_enqueue error: -4<br/> Jun 6 09:50:44 ehyperion354 LustreError: 25116:0:(file.c:3331:ll_inode_revalidate_fini()) failure -4 inode 180355073<br/> Jun 6 09:50:44 ehyperion354 LustreError: 25303:0:(client.c:858:ptlrpc_import_delay_req()) @@@ IMP_INVALID req@ffff810162637400 x1403992855059565/t0 o101-&gt;lustre-MDT0000_UUID@192.168.120.126@o2ib:12/10 lens 544/1232 e 0 to 1 dl 0 ref 1 fl Rpc:/0/0 rc 0/0</p> LU-1488

2.1.2 servers, 1.8.8 clients _mdc_blocking_ast()) ### data mismatch with ino

Bug Major Resolved Fixed Yang Sheng Cliff White Wed, 6 Jun 2012 14:04:18 +0000 Fri, 22 Feb 2013 11:15:59 +0000 Fri, 17 Aug 2012 09:06:47 +0000 Lustre 1.8.8 Lustre 1.8.9 0 6 <p>This is interesting, but hopefully not a difficult problem to fix...</p> <p>The inode number is reported as ino = 144115305952584894 = 0x200001b720024be, gen = 0, while the lock resource is reported as ino = 8589941618 = 0x200001b72, gen = 9406 = 0x24be. So there is no <em>real</em> problem here (i.e. no mismatch of ino/generation between the inode and the DLM lock), but it just isn't comparing the two values correctly. The inode number is the "flattened" version, while the DLM lock has the proper "FID":</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> fid = ll_inode_lu_fid(inode); : : <span class="code-keyword">if</span> (!fid_res_name_eq(fid, &amp;lock-&gt;l_resource-&gt;lr_name)) { LDLM_ERROR(lock, <span class="code-quote">"data mismatch with ino %lu/%u (%p)"</span>, inode-&gt;i_ino, inode-&gt;i_generation, inode); } </pre> </div></div> <p>However, this doesn't totally explain the problem away, because the "fid" being compared is from ll_i2info(inode)-&gt;ll_fid.f20, but LDLM_ERROR() doesn't actually print the "fid" value. It isn't clear if the flattened inode number is <em>actually</em> stored in lu_fid, or perhaps it is just uninitialized and failing the comparison for that reason, or is just full of garbage?</p> <p>If I had any skill with systemtap it would probably be possible to print out "fid" when this check fails, without having to submit a patch to do the same, build, land, install, and retest.</p> <p>Just test Lustre 2.2.0 servers with 1.8.8 and I saw the same problem.</p> <p>Bob</p> <p>Could you please look into this one?</p> <p>Thanks</p> <p>Peter</p> <p>Yangsheng will look into this one</p> <p>This issue cause by commit ef8bd11416bae8c03a65682f3a10a4da39922b45. The fid_build_reg_res_name() &amp; fid_res_name_eq() use different way build &amp; compare lu_fid &amp; res. I'll produce a patch to fix it.</p> <p>Patch upload to <a href="http://review.whamcloud.com/3522" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/3522</a>.</p> <p>Is there no way to fix this from the 2.X side?</p> <p>I don't think this issue will cause a real problem. We only reference fid_res_name_eq() in ll_mdc_blocking_ast() and just doing a check and output a error message. In fact, it harmless. </p> <p>Alright, thanks!</p> <p>I think b1_8 has some issue run on test system, Please take a look for <a href="http://review.whamcloud.com/3539" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/3539</a> . I just change lustre/ChangeLog. It still failed in same result and it works well when i download the packages on my local box.</p> <p>Fix landed for b1_8</p> Development Rank 1|hzvgw7: Rank (Obsolete) 6386 Severity