[Gluster-devel] Should we enable features.locks-notify.contention by default ?
xhernandez at redhat.com
Thu May 30 08:33:54 UTC 2019
On Thu, May 30, 2019 at 9:03 AM Ashish Pandey <aspandey at redhat.com> wrote:
> I am only concerned about in-service upgrade.
> If a feature/option is not present in V1, then I would prefer not to
> enable it by default on V2.
The problem is that without enabling it, (other-)eager-lock will cause
performance issues in some cases. It doesn't seem good to keep an option
disabled if enabling it solves these problems.
> We have seen some problem in other-eager-lock when we changed it to enable
> by default.
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.
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't see any problem right now.
Am I missing something ?
> *From: *"Amar Tumballi Suryanarayan" <atumball at redhat.com>
> *To: *"Xavi Hernandez" <xhernandez at redhat.com>
> *Cc: *"gluster-devel" <gluster-devel at gluster.org>
> *Sent: *Thursday, May 30, 2019 12:04:43 PM
> *Subject: *Re: [Gluster-devel] Should we enable
> features.locks-notify.contention by default ?
> On Thu, May 30, 2019 at 11:34 AM Xavi Hernandez <xhernandez at redhat.com>
>> Hi all,
>> a patch  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).
>> 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.
>> I think we should enabled it by default. Does anyone see any possible
>> issue if we do that ?
> If it helps performance, we should ideally do it.
> 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's opinion here.
>>  https://review.gluster.org/c/glusterfs/+/14736
> Amar Tumballi (amarts)
> Community Meeting Calendar:
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
> Gluster-devel mailing list
> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel