<div dir="ltr"><div dir="ltr">On Thu, May 30, 2019 at 9:03 AM Ashish Pandey &lt;<a href="mailto:aspandey@redhat.com">aspandey@redhat.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><div>I am only concerned about in-service upgrade.<br></div><div>If a feature/option is not present in V1, then I would prefer not to enable it by default on V2.<br></div></div></div></blockquote><div><br></div><div>The problem is that without enabling it, (other-)eager-lock will cause performance issues in some cases. It doesn&#39;t seem good to keep an option disabled if enabling it solves these problems.</div><br class="gmail-Apple-interchange-newline"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div></div><div>We have seen some problem in other-eager-lock when we changed it to enable by default.<br></div></div></div></blockquote><div><br></div><div>Which problems ? I think the only issue with other-eager-lock has been precisely that locks-notify-contention was disabled and a bug that needed to be solved anyway.</div><div><br></div><div>The difference will be that upgraded bricks will start sending upcall notifications. If clients are too old, these will simply be ignored. So I don&#39;t see any problem right now.</div><div><br></div><div>Am I missing something ?</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><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div></div><div><br></div><div>---<br></div><div>Ashish<br></div><div><br></div><hr id="gmail-m_6290257180219516839zwchr"><div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>&quot;Amar Tumballi Suryanarayan&quot; &lt;<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>&gt;<br><b>To: </b>&quot;Xavi Hernandez&quot; &lt;<a href="mailto:xhernandez@redhat.com" target="_blank">xhernandez@redhat.com</a>&gt;<br><b>Cc: </b>&quot;gluster-devel&quot; &lt;<a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a>&gt;<br><b>Sent: </b>Thursday, May 30, 2019 12:04:43 PM<br><b>Subject: </b>Re: [Gluster-devel] Should we enable features.locks-notify.contention by default ?<br><div><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 30, 2019 at 11:34 AM Xavi Hernandez &lt;<a href="mailto:xhernandez@redhat.com" target="_blank">xhernandez@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">Hi all,<br><div><br></div><div>a patch [1] was added some time ago to send upcall notifications from the locks xlator to the current owner of a granted lock when another client tries to acquire the same lock (inodelk or entrylk). This makes it possible to use eager-locking on the client side, which improves performance significantly, while also keeping good performance when multiple clients are accessing the same files (the current owner of the lock receives the notification and releases it as soon as possible, allowing the other client to acquire it and proceed very soon).</div><div><br></div><div>Currently both AFR and EC are ready to handle these contention notifications and both use eager-locking. However the upcall contention notification is disabled by default.</div><div><br></div><div>I think we should enabled it by default. Does anyone see any possible issue if we do that ?</div><div><br></div></div></blockquote><div><br class="gmail-m_6290257180219516839gmail-Apple-interchange-newline">If it helps performance, we should ideally do it.<div><br></div><div>But, considering we are days away from glusterfs-7.0 branching, should we do it now, or wait for branch out, and make it default for next version? (so that it gets time for testing). Considering it is about consistency I would like to hear everyone&#39;s opinion here.</div><div><br></div><div>Regards,</div><div>Amar</div></div><div><br></div><div><br></div><div> </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><br></div><div>Xavi</div><div><br></div><div>[1] <a href="https://review.gluster.org/c/glusterfs/+/14736" target="_blank">https://review.gluster.org/c/glusterfs/+/14736</a><br></div></div>_______________________________________________<br> <br></blockquote></div><div><br></div>-- <br><div dir="ltr" class="gmail-m_6290257180219516839gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div></div><br>_______________________________________________<br><div><br></div>Community Meeting Calendar:<br><div><br></div>APAC Schedule -<br>Every 2nd and 4th Tuesday at 11:30 AM IST<br>Bridge: <a href="https://bluejeans.com/836554017" target="_blank">https://bluejeans.com/836554017</a><br><div><br></div>NA/EMEA Schedule -<br>Every 1st and 3rd Tuesday at 01:00 PM EDT<br>Bridge: <a href="https://bluejeans.com/486278655" target="_blank">https://bluejeans.com/486278655</a><br><div><br></div>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" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br><div><br></div></div><div><br></div></div></div></blockquote></div></div>