[Gluster-devel] Should we enable contention notification by default ?

Xavi Hernandez xhernandez at redhat.com
Thu May 2 10:45:38 UTC 2019

Hi all,

there's a feature in the locks xlator that sends a notification to current
owner of a lock when another client tries to acquire the same lock. This
way the current owner is made aware of the contention and can release the
lock as soon as possible to allow the other client to proceed.

This is specially useful when eager-locking is used and multiple clients
access the same files and directories. Currently both replicated and
dispersed volumes use eager-locking and can use contention notification to
force an early release of the lock.

Eager-locking reduces the number of network requests required for each
operation, improving performance, but could add delays to other clients
while it keeps the inode or entry locked. With the contention notification
feature we avoid this delay, so we get the best performance with minimal
issues in multiclient environments.

Currently the contention notification feature is controlled by the
'features.lock-notify-contention' option and it's disabled by default.
Should we enable it by default ?

I don't see any reason to keep it disabled by default. Does anyone foresee
any problem ?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190502/330a0c0f/attachment.html>

More information about the Gluster-devel mailing list