[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 [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).
> 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.


> Regards,
> Xavi
> [1] https://review.gluster.org/c/glusterfs/+/14736
> _______________________________________________
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190530/59055be2/attachment.html>

More information about the Gluster-devel mailing list