[Gluster-devel] Should we enable features.locks-notify.contention by default ?
Amar Tumballi Suryanarayan
atumball at redhat.com
Thu May 30 06:34:43 UTC 2019
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel