Bug 1717282 - ec ignores lock contention notifications for partially acquired locks
Summary: ec ignores lock contention notifications for partially acquired locks
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: disperse
Version: 5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On: 1708156
Blocks: glusterfs-5.7 1714172
TreeView+ depends on / blocked
 
Reported: 2019-06-05 05:52 UTC by Xavi Hernandez
Modified: 2019-07-02 04:40 UTC (History)
1 user (show)

Fixed In Version:
Clone Of: 1708156
Environment:
Last Closed: 2019-07-02 04:40:42 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gluster.org Gerrit 22822 0 None Merged cluster/ec: honor contention notifications for partially acquired locks 2019-07-02 04:40:40 UTC

Description Xavi Hernandez 2019-06-05 05:52:32 UTC
+++ This bug was initially created as a clone of Bug #1708156 +++

Description of problem:

When an inodelk is being acquired, it could happen that some bricks have already granted the lock while others don't. From the point of view of ec, the lock is not yet acquired.

If at this point one of the bricks that has already granted the lock receives another inodelk request, it will send a contention notification to ec.

Currently ec ignores those notifications until the lock is fully acquired. This means than once ec acquires the lock on all bricks, it won't be released immediately when eager-lock is used.

Version-Release number of selected component (if applicable): mainline


How reproducible:

Very frequently when there are multiple concurrent operations on same directory

Steps to Reproduce:
1. Create a disperse volume
2. Mount it from several clients
3. Create few files on a directory
4. Do 'ls' of that directory at the same time from all clients

Actual results:

Some 'ls' take several seconds to complete

Expected results:

All 'ls' should complete in less than a second

Additional info:

Comment 1 Worker Ant 2019-06-05 05:54:55 UTC
REVIEW: https://review.gluster.org/22822 (cluster/ec: honor contention notifications for partially acquired locks) posted (#1) for review on release-5 by Xavi Hernandez

Comment 2 Worker Ant 2019-07-02 04:40:42 UTC
REVIEW: https://review.gluster.org/22822 (cluster/ec: honor contention notifications for partially acquired locks) merged (#4) on release-5 by hari gowtham


Note You need to log in before you can comment on or make changes to this bug.