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-5557 Lustre <p>MDS <tt>stats</tt> proc file <tt>/proc/fs/lustre/mds/MDS/mdt/stats</tt> does not track information about LDLM_ENQUEUE and MDS_REINT RPCs.<br/> This class of RPC covers most of "modifying" RPCs on MDS. This file displays mostly RPC that "read" data from MDT device and which is not "writing" on the device.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ cat /proc/fs/lustre/mds/MDS/mdt/stats snapshot_time 1409239309.161365 secs.usecs req_waittime 182 samples [usec] 17 420 19191 2604647 req_qdepth 182 samples [reqs] 0 1 3 3 req_active 182 samples [reqs] 1 3 251 403 req_timeout 182 samples [sec] 1 10 209 479 reqbuf_avail 463 samples [bufs] 64 64 29632 1896448 ldlm_ibits_enqueue 5 samples [reqs] 1 1 5 5 mds_getattr 1 samples [usec] 83 83 83 6889 mds_connect 6 samples [usec] 20 197 439 54031 mds_getstatus 1 samples [usec] 76 76 76 5776 mds_statfs 2 samples [usec] 74 95 169 14501 obd_ping 167 samples [usec] 12 130 5875 249977 </pre> </div></div> <p>These class of RPCs are explicitly blacklisted in the code for a very long time.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>+++ b/lustre/ptlrpc/service.c @@ -2110,7 +2110,7 @@ put_conn: if (likely(svc-&gt;srv_stats != NULL &amp;&amp; request-&gt;rq_reqmsg != NULL)) { __u32 op = lustre_msg_get_opc(request-&gt;rq_reqmsg); int opc = opcode_offset(op); if (opc &gt; 0 &amp;&amp; !(op == LDLM_ENQUEUE || op == MDS_REINT)) { LASSERT(opc &lt; LUSTRE_MAX_OPCODES); lprocfs_counter_add(svc-&gt;srv_stats, opc + EXTRA_MAX_OPCODES, </pre> </div></div> <p>Is there some specific reasons to prevent that?</p> <p>Could we consider enabling them?</p> LU-5557

enqueue and reint RPC are not tracked in MDS stats

Improvement Minor Resolved Fixed John Hammond Aurelien Degremont llnl Thu, 28 Aug 2014 15:28:51 +0000 Mon, 6 Oct 2014 12:02:09 +0000 Mon, 6 Oct 2014 11:56:20 +0000 Lustre 2.6.0 Lustre 2.5.2 Lustre 2.4.3 Lustre 2.7.0 1 7 <p>I think John already has a patch to fix this. </p> <p>I did. I'll restore it and look at addressing your comments.</p> <p>On this subject, is it in out long term interest to replace these jumbo opcodes (MDS_REINT and LDLM_ENQUEUE) with specific opcodes (MDS_OPEN, MDS_CREATE, MDS_UNLINK, ...)? It has been pointed out that this would make RPC traces much more useful. I'm not sure what "reint" means and I don't think that if I knew it would help anything.</p> <p>Once upon a time, there was a filesystem named Intermezzo that allowed clients to disconnect from the server while using and optionally modifying their locally cached copy of the data. When the client reconnected to the server, it would reintegrate the log of changes that it had made locally to get the server copy back in sync with the client. The thought for Lustre was to allow clients to eventually do the same thing.</p> <p>Initially, Lustre clients would only send individual reintegration records to the MDT to change the metadata, but in the future it would be possible to reintegrate a series of changes efficiently, allowing either writeback caching (WBC) clients and/or disconnected operation. In that case, the type of any individual operation isn't known in advance, and there may in fact be multiple different operations sent in the same RPC. Hence, there is only the MDS_REINT RPC type instead of separate RPC handlers for each update type. That said, it would be possible to send different RPC types for statistical purposes, and have all of the RPC handlers be the same piece of code.</p> <p>Similarly, while LDLM_ENQUEUE today is commonly used for open (along with an open intent), it may be used for other kinds of locking operations on the MDS (e.g re-enqueue a lock in revalidate after it has been cancelled due to conflict) as well as extent locks on the OSS. I don't think it would be possible to change LDLM_ENQUEUE to MDS_OPEN as a result.</p> <p>I also recently found <a href="http://review.whamcloud.com/342" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/342</a> which fixes up some of this same code.</p> <p>&gt; Similarly, while LDLM_ENQUEUE today is commonly used for open (along with an open intent), it may be used for other kinds of locking operations on the MDS (e.g re-enqueue a lock in revalidate after it has been cancelled due to conflict) as well as extent locks on the OSS. I don't think it would be possible to change LDLM_ENQUEUE to MDS_OPEN as a result.</p> <p>Then MDS_ENQUEUE_OPEN.</p> <p>Please see <a href="http://review.whamcloud.com/11924" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/11924</a> for the reint stats.</p> <p>Landed for 2.7</p> <p>Could we consider this for 2.5.4 ?</p> Development Rank 1|hzwuuv: Rank (Obsolete) 15496