<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 22, 2014 at 11:49 PM, Pranith Kumar Karampuri <span dir="ltr">&lt;<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
    When iozone is in progress and the number of blocking inodelks is greater than the threshold number of rpc requests allowed for that client (RPCSVC_DEFAULT_OUTSTANDING_RPC_LIMIT), subsequent requests from that client will not be read until all the outstanding requests are processed and replied to. But because no more requests are read from that client, unlocks on the already granted locks will never come thus the number of outstanding requests would never come down. This leads to a ping-timeout on the client. I am wondering if the proper fix for this is to not account INODELK/ENTRYLK/LK calls for throttling. I did make such a change in the codebase and tested it and it works. Please let me know if this is acceptable or it needs to be fixed differently.<br>
</blockquote><div><br></div><div><br></div><div>Do you know why there were &gt; 64 outstanding inodelk requests? What does iozone do to result in this kind of a locking pattern?</div><div><br></div></div></div></div>