+++ This bug was initially created as a clone of Bug #1314649 +++ Description of problem: If a fop takes lock, and completes its operation, it waits for 1 second before releasing the lock. However, If ec find any lock contention within this time period, it release the lock immediately before time expires. As we take lock on first brick, In some operation, like read, it might happen that discovery of lock contention might take long time and can degrades the performance. Provide an option to enable/disable eager lock Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from Vijay Bellur on 2016-03-04 03:06:06 EST --- REVIEW: http://review.gluster.org/13605 (cluster/ec: Provide an option to enable/disable eager lock) posted (#1) for review on master by Ashish Pandey (aspandey) --- Additional comment from Vijay Bellur on 2016-03-11 02:44:55 EST --- REVIEW: http://review.gluster.org/13605 (cluster/ec: Provide an option to enable/disable eager lock) posted (#2) for review on master by Ashish Pandey (aspandey) --- Additional comment from Vijay Bellur on 2016-03-14 03:13:38 EDT --- REVIEW: http://review.gluster.org/13605 (cluster/ec: Provide an option to enable/disable eager lock) posted (#3) for review on master by Ashish Pandey (aspandey) --- Additional comment from Vijay Bellur on 2016-03-15 01:41:30 EDT --- REVIEW: http://review.gluster.org/13605 (cluster/ec: Provide an option to enable/disable eager lock) posted (#4) for review on master by Ashish Pandey (aspandey) --- Additional comment from Vijay Bellur on 2016-03-16 00:54:35 EDT --- COMMIT: http://review.gluster.org/13605 committed in master by Pranith Kumar Karampuri (pkarampu) ------ commit 23ccabbeb7879fd05f415690124bd7b4a74d4d33 Author: Ashish Pandey <aspandey> Date: Fri Mar 4 13:05:09 2016 +0530 cluster/ec: Provide an option to enable/disable eager lock Problem: If a fop takes lock, and completes its operation, it waits for 1 second before releasing the lock. However, If ec find any lock contention within this time period, it release the lock immediately before time expires. As we take lock on first brick, for few operations, like read, it might happen that discovery of lock contention might take long time and can degrades the performance. Solution: Provide an option to enable/disable eager lock. If eager lock is disabled, lock will be released as soon as fop completes. gluster v set <VOLUME NAME> disperse.eager-lock on gluster v set <VOLUME NAME> disperse.eager-lock off Change-Id: I000985a787eba3c190fdcd5981dfbf04e64af166 BUG: 1314649 Signed-off-by: Ashish Pandey <aspandey> Reviewed-on: http://review.gluster.org/13605 Smoke: Gluster Build System <jenkins.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu> Tested-by: Pranith Kumar Karampuri <pkarampu> CentOS-regression: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org>
REVIEW: http://review.gluster.org/13773 (cluster/ec: Provide an option to enable/disable eager lock) posted (#1) for review on release-3.7 by Ashish Pandey (aspandey)
REVIEW: http://review.gluster.org/13773 (cluster/ec: Provide an option to enable/disable eager lock) posted (#2) for review on release-3.7 by Ashish Pandey (aspandey)
COMMIT: http://review.gluster.org/13773 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) ------ commit 46920e3bd38d9ae7c1910d0bd83eff309ab20c66 Author: Ashish Pandey <aspandey> Date: Fri Mar 4 13:05:09 2016 +0530 cluster/ec: Provide an option to enable/disable eager lock Problem: If a fop takes lock, and completes its operation, it waits for 1 second before releasing the lock. However, If ec find any lock contention within this time period, it release the lock immediately before time expires. As we take lock on first brick, for few operations, like read, it might happen that discovery of lock contention might take long time and can degrades the performance. Solution: Provide an option to enable/disable eager lock. If eager lock is disabled, lock will be released as soon as fop completes. gluster v set <VOLUME NAME> disperse.eager-lock on gluster v set <VOLUME NAME> disperse.eager-lock off master- http://review.gluster.org/13605 Change-Id: I000985a787eba3c190fdcd5981dfbf04e64af166 BUG: 1318965 Signed-off-by: Ashish Pandey <aspandey> Reviewed-on: http://review.gluster.org/13773 Smoke: Gluster Build System <jenkins.com> CentOS-regression: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: Pranith Kumar Karampuri <pkarampu>
patch already available in 3.7 code base : http://review.gluster.org/#/c/13773/
REVIEW: http://review.gluster.org/13958 (extras: Add namespace for options in group-virt.example) posted (#1) for review on release-3.7 by Kaushal M (kaushal)
REVIEW: http://review.gluster.org/13958 (extras: Add namespace for options in group-virt.example) posted (#2) for review on release-3.7 by Kaushal M (kaushal)
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.10, please open a new bug report. glusterfs-3.7.10 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://www.gluster.org/pipermail/gluster-users/2016-April/026164.html [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user