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-6284 Lustre <p> The <tt>RQF_FLD_READ</tt> RPC reply format is defined with "generic_data" (<tt>RQF_GENERIC_DATA</tt>) as the second field, but in fact this is always <tt>struct lu_seq_range_array</tt> in the two places that I see it used. Since <tt>RQF_FLD_READ</tt> does not have any swabber associated with generic data, the client will not swab the FLD reply data.</p> <p>That doesn't cause a problem for current code, because it always assumes MDT0000 for any FID lookup, and we haven't tested DNE + PPC client systems yet, nor do we have mixed-endian MDS/OSS combinations. However, this will break for DNE + PPC clients and should be fixed.</p> LU-6284

FLD read is not swabbed correctly

Bug Minor Resolved Fixed nasf Andreas Dilger llnl ppc Wed, 25 Feb 2015 21:00:23 +0000 Tue, 14 Mar 2017 21:18:46 +0000 Sat, 10 Sep 2016 04:23:54 +0000 Lustre 2.8.0 Lustre 2.9.0 0 6 <p>This is likely causing problems for ppc_review-dne-part-<span class="error">&#91;12&#93;</span> testing.</p> <p>Fan Yong</p> <p>Could you please help with this one?</p> <p>Thanks</p> <p>Peter</p> <p>I have checked the current master and found that both the FLD-server and FLD-client have handled "lu_seq_range_array" properly as following:</p> <p>On the server side:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>int fld_server_read(const struct lu_env *env, struct lu_server_fld *fld, struct lu_seq_range *range, void *data, int data_len) { ... if (rc &gt; 0) rc = 0; out: ==&gt; range_array_cpu_to_le(lsra, lsra); ... } </pre> </div></div> <p>On the client side:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>int fld_update_from_controller(const struct lu_env *env, struct lu_server_fld *fld) { ... do { rc = fld_client_rpc(fld-&gt;lsf_control_exp, range, FLD_READ, &amp;req); if (rc != 0 &amp;&amp; rc != -EAGAIN) GOTO(out, rc); LASSERT(req != NULL); lsra = (struct lu_seq_range_array *)req_capsule_server_get( &amp;req-&gt;rq_pill, &amp;RMF_GENERIC_DATA); if (lsra == NULL) GOTO(out, rc = -EPROTO); ==&gt; range_array_le_to_cpu(lsra, lsra); ... } </pre> </div></div> <p>That means before the server replying FLD_READ RPC, it will convert the "lu_seq_range_array" as little-endian mode via "range_array_cpu_to_le()". And when the client receives the FLD_READ reply, it will converts the little-endian mode "lu_seq_range_array" to CPU mode via "range_array_le_to_cpu()". So there should be no cross-platforms interoperability trouble.</p> <p>Is there a reason we don't just register <tt>range_array_le_to_cpu()</tt> as the swabber for this buffer so that it is swabbed like normal RPC buffers as part of the RPC handling?</p> <p>Honestly, I do not know the original reason for why not registered a swabber() as other RPCs do. Do you think it is good time to adjust that now? </p> <p>Hmm, it seems that range_array_le_to_cpu() would not be a proper function for swabbing the buffer, since this would convert the array to little endian instead of host endian. If this is registered as the swabbed function it would need to always swab the array if it is called, but it would only be called if swabbing is needed. </p> <p>Yes, the current implementation will transfer the buffer as little endian on the network, and convert it as host endian in RAM when handle it. Comparing with the registered swabber solution that is only called when necessary, current implementation is NOT efficient, anyway it can work. If we replace it with the registered swabber as other RPCs do, that may cause some interoperability trouble if the peer (different host endian) still uses range_array_{le,cpu}<em>to</em>{cpu,le}. I think that if there will be some other on-wire protocol changes in the future, then it will be good time-point to adjust it.</p> <p>If we have only ever supported little-endian servers, then the only clients that would need to swab would be PPC clients, so I don't think this should cause any problems...</p> <p>I may found why we did not registered a swabber() for 'FLD_READ' RPC. In theory, we can do that. But from the implementation view, it is not easy to be done within our current "struct req_msg_field" framework. Because the sequence range array is not fixed length, instead, its length depends on the 'lu_seq_range' count, that is unknown when prepare the RPC buffer. Generally, for such flexible length RPC usage, there will be a field in the RPC layout to indicate the data length. But for 'FLD_READ' RPC, we have no way to indicate the length unless we add new length filed that will broken the on-wire RPC protocol.</p> <p>I think the only thing that may be needed here is to add a comment at the swabbed function and at the struct definition that includes the explanation here about what is happening and why. </p> <p>Here is the patch on master:<br/> <a href="http://review.whamcloud.com/22309" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/22309</a></p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/22309/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/22309/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6284" title="FLD read is not swabbed correctly" class="issue-link" data-issue-key="LU-6284"><del>LU-6284</del></a> ptlrpc: comment for FLD_QUERY RPC reply swab<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 8d8a153e12437900a876293dedc3cc657810ee83</p> <p>Landed for 2.9</p> Related LU-6831 LU-5345 LU-6387 Development Rank 1|hzx72f: Rank (Obsolete) 17615 Severity