<div dir="ltr"><div><div><div>Krutika,<br><br></div>This patch doesn't seem to be getting counts per domain, like number of inodelks or entrylks acquired in a domain "xyz". Am I right? If per domain stats are not available, passing interested domains in xdata_req would be needed. Any suggestions on that?<br><br></div>regards,<br></div>Raghavendra<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 20, 2018 at 12:58 PM, Raghavendra Gowdappa <span dir="ltr"><<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jun 20, 2018 at 12:06 PM, Krutika Dhananjay <span dir="ltr"><<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We do already have a way to get inodelk and entrylk count from a bunch of fops, introduced in <a href="http://review.gluster.org/10880" target="_blank">http://review.gluster.org/1088<wbr>0</a>.</div><div>Can you check if you can make use of this feature?</div></div></blockquote><div><br></div></span><div>Thanks Krutika. Yes, this feature meets DHT's requirement. We might need a GLUSTERFS_PARENT_INODELK, but that can be easily added along the lines of other counts. If necessary I'll send a patch to implement GLUSTERFS_PARENT_INODELK.</div><div><div class="h5"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>-Krutika<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_3566330009781316678h5">On Wed, Jun 20, 2018 at 9:17 AM, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_3566330009781316678h5"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Jun 20, 2018 at 9:06 AM, Raghavendra Gowdappa <span dir="ltr"><<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div>All,<br><br></div>We've a requirement in DHT [1] to query the number of locks granted on an inode in lookup fop. I am planning to use xdata_req in lookup to pass down the relevant arguments for this query. I am proposing following signature:<br><br></div>In lookup request path following key value pairs will be passed in xdata_req:<br></div>* "glusterfs.lock.type" <br></div> - values can be "glusterfs.posix", "glusterfs.inodelk", "glusterfs.entrylk"<br></div>* If the value of "glusterfs.lock.type" is "glusterfs.entrylk", then basename is passed as a value in xdata_req for key "glusterfs.entrylk.basename"</div><div>* key "glusterfs.lock-on?" will differentiate whether the lock information is on current inode ("glusterfs.current-inode") or parent-inode ("glusterfs.parent-inode"). For a nameless lookup "glusterfs.parent-inode" is invalid.<br></div><div>* "glusterfs.blocked-locks" - Information should be limited to blocked locks.</div><div>* "glusterfs.granted-locks" - Information should be limited to granted locks.<br></div>* If necessary other information about granted locks, blocked locks can be added. Since, there is no requirement for now, I am not adding these keys.<br><br></div>Response dictionary will have information in following format:<br></div></div>* "glusterfs.entrylk.<gfid>.<bas<wbr>ename>.granted-locks" - number of granted entrylks on inode "gfid" with "basename" (usually this value will be either 0 or 1 unless we introduce read/write lock semantics).<br></div>* "glusterfs.inodelk.<gfid>.gran<wbr>ted-locks" - number of granted inodelks on "basename"<br><div><div><div><div><br><div><div><div><div>Thoughts?<br></div><div><div><br></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div></span><div>I personally feel, it is good to get as much information possible in lookup, so it helps to take some high level decisions better, in all translators. So, very broad answer would be to say go for it. The main reason the xdata is provided in all fops is to do these extra information fetching/overloading anyways.</div><div><br></div><div>As you have clearly documented the need, it makes it even better to review and document it with commit. So, all for it.</div><div><br></div><div>Regards,</div><div>Amar</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1581306#c28" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1581306#c28</a></div><div><br></div></div></div></div></div></div></div></div></div></div></blockquote></div>
</div></div>
<br></div></div>______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>