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-3279 Lustre <p>This issue was created by maloo for sarah &lt;sarah@whamcloud.com&gt;</p> <p>This issue relates to the following test suite run: <a href="http://maloo.whamcloud.com/test_sets/5584e96e-b5de-11e2-9d08-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">http://maloo.whamcloud.com/test_sets/5584e96e-b5de-11e2-9d08-52540035b04c</a>.</p> <p>The sub-test test_7 failed with the following error:</p> <blockquote> <p>Failure in replication; differences found.</p></blockquote> <p>Info required for matching: lustre-rsync-test 7</p> client: 2.3.0<br/> server: <a href="http://review.whamcloud.com/#change,6252">http://review.whamcloud.com/#change,6252</a> patch set 5<br/> client uses the t-f.sh from server LU-3279

Interop 2.3.0 <-> 2.4 failure on test suite lustre-rsync-test test_7: Failure in replication; differences found

Bug Major Resolved Fixed Mikhail Pershin Maloo MB Mon, 6 May 2013 00:31:33 +0000 Wed, 26 Jun 2013 16:42:47 +0000 Mon, 20 May 2013 16:01:22 +0000 Lustre 2.4.0 Lustre 2.4.0 Lustre 2.1.6 0 15 <p>Mike,<br/> Could you please comment on this one?<br/> Thank you!</p> <p>Di, Mike,<br/> the problem here appears to be that the ChangeLog user doesn't see any log records. Is there some change in the protocol that breaks interoperability with a 2.3 client? Does this bug need to be a blocker for 2.4.0?</p> <p>It seems 2.4 adds Layout changes log </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>50596 20LAYOUT 06:38:24.898596932 2013.05.07 0x0 t=[0x200000401:0x2e:0x0] </pre> </div></div> <p>which 2.3 clients do not recognize, which cause the failure of test_7. So it might not be a blocker.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Lustre: DEBUG MARKER: == lustre-rsync-test test 7: lustre_rsync stripesize == 22:54:01 (1367906041) LustreError: 9793:0:(mdc_request.c:1236:changelog_show_cb()) Not a changelog rec 275120128/20 LustreError: 9801:0:(mdc_request.c:1236:changelog_show_cb()) Not a changelog rec 275120128/20 </pre> </div></div> <p>Jinshan, could you please comment?</p> <p>it should not bee to had to filter out laouyt changes from a log to a client that does not understand layout lock?</p> <p>It seems there is nothing else we can do instead of requiring the customers to use uptodate client to do rsync.</p> <p>I don't think to filter out the unknown record is an option because that will make rsync not work practically.</p> <p>Jinshan - that depends on what records are being filtered out. 275120128 = 0x10660000 = CHANGELOG_REC, and 20 = CL_LAYOUT. The CL_LAYOUT records do not affect the actual data in the file, which is what lustre_rsync cares about.</p> <p>To be honest, I don't think the kernel should actually <em>care</em> about what is in the ChangeLog, it should only be the consumer that needs to check what the records are. changelog_show_cb() should IMHO be modified to remove the CL_LAST check, and just pass all of the records on to the consumer. Otherwise, we will have all sorts of "compatibility" problems here for no real benefit.</p> <p>If necessary, we might consider to split up the cr_type field to contain a few bits of information, like:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">#define CL_FLAG_OPTIONAL 0xff000000 <span class="code-comment">/* does not affect data content/layout, can be skipped */</span> </pre> </div></div> <p>For now, to keep things simple, I've pushed <a href="http://review.whamcloud.com/6308" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6308</a> to fix this interop problem. It moves CL_LAYOUT in the place of CL_IOCTL (which was never used, and was IMHO a pointless record). This avoids the problem of CL_LAYOUT &gt; CL_LAST(2.3). It also removes the check for cr_type &gt; CL_LAST, and just passes the records up to the caller, and the caller can decide what to do with the records. It does not do anything like CL_FLAG_OPTIONAL, but we might consider that in the future.</p> <p>Just a heads up to CEA and LLNL:</p> <p>Current patch in review changes LAYOUT changelog record type to an incompatible value. Do you guys currently monitor it from your tools, would you be affected by the change?</p> <p>I appreciate the heads up! <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/>. AFAIK, we do not use any tools external to the Lustre tree which make use of changelogs except robinhood. Can one of the robinhood developers comment on this? I'm not familiar with its internals to know if it would affect it or not..</p> <p>Thanks for the heads up. The change doesn't affect our tools.</p> <p>We have concerns about the comment that has been added to lustre/lustre_user.h:650 though. As Jinshan Xiong noted, stating that CL_LAYOUT doesn't reflect any actual data change is misleading.</p> <p>interop between 2.1.5 client and 2.4 server also hit this issue in tag-2.3.65 testing:</p> <p><a href="https://maloo.whamcloud.com/test_sets/3e989b54-b9a5-11e2-875f-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/3e989b54-b9a5-11e2-875f-52540035b04c</a></p> <blockquote> <p>We have concerns about the comment that has been added to lustre/lustre_user.h:650 though. As Jinshan Xiong noted, stating that CL_LAYOUT doesn't reflect any actual data change is misleading.</p></blockquote> <p>My thought is that the <em>content</em> of the file is not changing, either in the case of file release and file migrate. In the case of file release, the <em>content</em> is still in the archive. Even if it is not in Lustre, any application accessing that file would get the same data back after it is restored from the archive.</p> <p>There is of course some concern that a poorly-written layout swap <em>could</em> change the content of the file (e.g. source and target file do not contain the same data), but I can't see any reason to do that. Only the file owner could do this migrate, and they could just as easily write some other data directly into the file if they want.</p> <p>In any case, I'll remove the comment from the CL_LAYOUT description.</p> <p>I've pushed <a href="http://review.whamcloud.com/6338" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6338</a> as a follow-on patch for master. This changes the comment for CL_LAYOUT, and also changes the output string for this record type to match the 5-character convention used by other names.</p> <p>I pushed <a href="http://review.whamcloud.com/6335" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6335</a> as a combined patch for b2_1.</p> <p>Andreas</p> <p>All the present patches in flight have landed. Is any further work required or can this ticket be marked as resolved?</p> <p>Peter</p> Related LU-3190 Development Rank 1|hzvq6v: Rank (Obsolete) 8116 Severity