[Gluster-devel] Should we enable features.locks-notify.contention by default ?

[Amar Tumballi Suryanarayan]

On Thu, May 30, 2019 at 11:34 AM Xavi Hernandez <xhernandez at redhat.com>
wrote:

> 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,
Amar




> 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>