<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 10:57 PM FNU Raghavendra Manjunath &lt;<a href="mailto:rabhat@redhat.com">rabhat@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>The idea looks OK. One of the things that probably need to be considered (more of an implementation detail though) is how to generate frame-&gt;root-&gt;unique.</div><div><br></div><div>Because, for fuse, frame-&gt;root-&gt;unique is obtained by finh-&gt;unique which IIUC is got from the incoming fop from kernel itself.</div><div>For protocol/server IIUC frame-&gt;root-&gt;unique is got from req-&gt;xit of the rpc request, which itself is obtained from transport-&gt;xid of the rpc_transport_t structure (and from my understanding, the transport-&gt;xid is just incremented by everytime a</div><div>new rpc request is created).</div><div><br></div><div>Overall the suggestion looks fine though.</div></div></blockquote><div><br></div><div>I am planning to do the same thing transport-&gt;xid does. I will send out the patch<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div>Raghavendra</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 2:27 AM Pranith Kumar Karampuri &lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,<br></div><div>        At the moment new stack doesn&#39;t populate frame-&gt;root-&gt;unique in all cases. This makes it difficult to debug hung frames by examining successive state dumps. Fuse and server xlator populate it whenever they can, but other xlators won&#39;t be able to assign one when they need to create a new frame/stack. Is it okay to change create_frame() code to always populate it with an increasing number for this purpose?</div><div>     I checked both fuse and server xlator use it only in gf_log() so it doesn&#39;t seem like there is any other link between frame-&gt;root-&gt;unique and the functionality of fuse, server xlators.</div><div>      Do let me know if I missed anything before sending this change.</div><div><br>-- <br><div dir="ltr" class="gmail-m_-5027819941775530126gmail-m_7206816067631052765gmail_signature"><div dir="ltr">Pranith<br></div></div></div></div>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/836554017" rel="noreferrer" target="_blank">https://bluejeans.com/836554017</a><br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/486278655" rel="noreferrer" target="_blank">https://bluejeans.com/486278655</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Pranith<br></div></div></div>