<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>Is there way to run 2.5.3-llnl server with 1.8.9 client? </div>
<div>Or, do you have a hint what can be a problem causing LBUG when mounting two lustres (old 1.8.8 and new 2.5.3) from 1.8.9 client? No ldiskfs on new system, ZFS only.</div>
<div><br>
</div>
<div>I'm copying my previous posting at the end of the mail for specific error. Is it related to FID format changes and FID namespace ranges in 1.8 / 2.4 / 2.5 ?</div>
<div><br>
</div>
<div>Thanks, Alex.</div>
<div><br>
</div>
<div>
<div style="margin: 0px; font-family: Monaco;"></div>
<blockquote type="cite">
<div style="margin: 0px; font-family: Monaco;">Subject: lustre 1.8.9 client with LLNL server 2.5.3 LBUG</div>
<div style="margin: 0px; font-family: Monaco;">Date: Wed, 27 Jan 2016 15:29:24 -0600</div>
</blockquote>
</div>
<div style="margin: 0px 0px 0px 4px;"><br>
</div>
<div>
<blockquote type="cite">Does anyone have experience running lustre 1.8.9 client with LLNL server 2.5.3 (zfs)?
<div><br>
</div>
<div>
<div>I was almost instantly getting LBUG related to IGIF FID assertion after the mount:</div>
<div><br>
</div>
<div><span style="font-size: 13px;">dsg0515 kernel: LustreError: 30899:0:(mdc_fid.c:334:fid_le_to_cpu()) ASSERTION(fid_is_igif(dst) || fid_ver(dst) == 0) failed: [0x293e750000006ada:0x70f8b3:0xa721a500]</span></div>
</div>
<div>(full stack dump at the end of email).</div>
<div><br>
</div>
<div>This happened only when I tried to mount two lustre file systems (the old 1.8.9 servers and new 2.5.3 servers) on the same client 1.8.9 during the tests last summer. The new 2.5.3 system was freshly formatted and few data written from 2.5.3 client.</div>
<div>I would like to try llnl 2.5.3 server with 1.8.9 client again. </div>
<div><br>
</div>
<div>Apparently I'm missing something obvious.</div>
<div>I realize it is not supported or "tested" configuration, but we successfully running the similar configuration with last intel's GA release 2.5.3 server for more than half year with HPC clusters doing IO on both lustres and few nodes doing 'cp' between
old and new lustres, checksumming and stats.</div>
<div><br>
</div>
<div>We still need to have double mount (1.8 and 2.5) for another month till we finish migration. We will need to run 1.8.9 clients for six months more. I'm trying to reassess if I can use 2.5.3 llnl lustre on reinstalled servers in this configuration.</div>
<div><br>
</div>
<div>lustre 1.8.9 (or 2.5.3) client with LLNL server 2.5.3 only - runs fine.</div>
<div>lustre 1.8.9 client mounting both 1.8 servers and intel's 2.5.3 servers - runs fine.</div>
<div>lustre 1.8.9 client mounting both 1.8 servers and llnl 2.5.3 servers - crash after mount or few operations.</div>
<div>I was able to make it to last longer by mounting in certain order and doing "ls" to few existing files, but it crashes some time later during IO.</div>
<div><br>
</div>
<div>The reported FIDs looks real, but also</div>
<div>
<div style="font-size: 13px;">
<div><span style="font-size: 14px;"><font face="Consolas">[<font color="#0746ff">0xdead0000</font>00100100<span class="Apple-tab-span" style="white-space: pre;">
</span>:0x200200<span class="Apple-tab-span" style="white-space: pre;"> </span>:0xdead0000]</font></span></div>
<div><span style="font-family: Consolas; font-size: 14px;">[0x5a5a5a5a5a5a5a5a</span><span class="Apple-tab-span" style="font-family: Consolas; font-size: 14px; white-space: pre;">
</span><span style="font-family: Consolas; font-size: 14px;">:0x5a5a5a5a</span><span class="Apple-tab-span" style="font-family: Consolas; font-size: 14px; white-space: pre;">
</span><span style="font-family: Consolas; font-size: 14px;">:0x5a5a5a5a]</span></div>
<div><span style="font-size: 14px;"><font face="Consolas"><br>
</font></span></div>
</div>
</div>
<div>which corresponds to </div>
<div><span style="font-size: 13px;">CONFIG_ILLEGAL_POINTER_VALUE</span></div>
<div><span style="font-size: 13px;"># define LI_POISON ((int)0x5a5a5a5a) or like</span></div>
<div><span style="font-size: 13px;"> </span></div>
<div>I tried to compare branches 2.5.3-llnl and whamcloud branch 2_5 tag 2.5.3, and also tag 2.5.3.90 .</div>
<div>I did not find commit messages related to IGIF FID in commits which differ, though I guess there can be code change not related to commit message in the patch I missed.</div>
<div><br>
</div>
<div>I would appreciate any hints were to look to make it work and what is the difference causing this LBUG.</div>
<div><br>
</div>
<div>Thank in advance, Alex.</div>
</blockquote>
<div><span style="font-size: 13px;"></span></div>
<div>
<div style="font-size: 13px;"></div>
</div>
<blockquote type="cite">
<div><span style="font-size: 13px;"><br>
</span></div>
<div>
<div style="font-size: 13px;">
<p>Jun 1 15:01:10 dsg0515 kernel: LustreError: 4541:0:(mdc_fid.c:334:fid_le_to_cpu()) ASSERTION(fid_is_igif(dst) || fid_ver(dst) == 0) failed: [0x600000005:0x7:0xffffffff]</p>
<p>Jun 1 15:01:10 dsg0515 kernel: LustreError: 4541:0:(mdc_fid.c:334:fid_le_to_cpu()) LBUG</p>
<p>Jun 1 15:01:10 dsg0515 kernel: Pid: 4541, comm: ls</p>
<p>Jun 1 15:01:10 dsg0515 kernel: </p>
<p>Jun 1 15:01:10 dsg0515 kernel: Call Trace:</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810df1c4>] ? generic_permission+0x24/0xc0</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffffa0eb3847>] libcfs_debug_dumpstack+0x57/0x80 [libcfs]</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffffa0eb3de6>] lbug_with_loc+0x76/0xe0 [libcfs]</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffffa1135ee5>] fid_le_to_cpu+0xa5/0xb0 [mdc]</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffffa11a3c45>] ll_readdir+0x935/0xb00 [lustre]</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810d5b47>] ? nameidata_to_filp+0x57/0x70</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810af1d9>] ? __inc_zone_state+0x9/0x70</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810a3099>] ? __lru_cache_add+0x9/0x70</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810a3119>] ? lru_cache_add_lru+0x19/0x40</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810e5710>] ? filldir+0x0/0xf0</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810e5710>] ? filldir+0x0/0xf0</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810e58ac>] vfs_readdir+0xac/0xd0</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff810e5b66>] sys_getdents+0x86/0xe0</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff81420def>] ? page_fault+0x1f/0x30</p>
<p>Jun 1 15:01:10 dsg0515 kernel: [<ffffffff8100b2fb>] system_call_fastpath+0x16/0x1b</p>
<p>Jun 1 15:01:10 dsg0515 kernel: </p>
<p>Jun 1 15:01:10 dsg0515 kernel: LustreError: dumping log to /tmp/lustre-log.1433188870.4541</p>
</div>
</div>
</blockquote>
</div>
<div><br>
</div>
<br>
<div>
<div>On Mar 1, 2016, at 3:44 PM, Drokin, Oleg <<a href="mailto:oleg.drokin@intel.com">oleg.drokin@intel.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><br>
On Mar 1, 2016, at 4:14 PM, Christopher J. Morrone wrote:<br>
<br>
<blockquote type="cite">On 03/01/2016 09:18 AM, Alexander I Kulyavtsev wrote:<br>
<br>
<blockquote type="cite">is tag 2.5.3.90 considered stable?<br>
</blockquote>
<br>
No. Generally speaking you do not want to use anything with number 50<br>
or greater for the fourth number unless you are helping out with testing<br>
during the development process.<br>
</blockquote>
<br>
I think you are mixing up things and it is the 3rd number at 50 or above<br>
that is the development code.<br>
<br>
<br>
<blockquote type="cite">2.5.3 was the last official release on branch b2_5 before it was<br>
discontinued.<br>
</blockquote>
<br>
<br>
In this case 2.5.3.90 is "almost" 2.5.4 but not quite.<br>
We wanted to have a tag in b2_5 before commits there ceased so that we can refer<br>
to it by a version number vs the "tip of b2_5".<br>
It contains various fixes on top of 2.5.3, but as far as I know, it did not<br>
undergo the actual release testing that the point release would normally undergo.<br>
<br>
Since the b2_5 at the time was a maintenance branch, we mostly tried to place<br>
important fixes there that should not have broken anything.<br>
But due to lack of proper release testing this could not be guaranteed by us,<br>
so using it is still a bit of a leap of faith, but not quite as much as say<br>
2.5.51.0 or 2.6.55.0 or the like.<br>
<br>
Bye,<br>
Oleg<br>
<br>
_______________________________________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.org</a><br>
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org<br>
</blockquote>
</div>
<br>
</body>
</html>