Bug 1291762 - Improve handling of fcntl blocking lock requests
Summary: Improve handling of fcntl blocking lock requests
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: locks
Version: mainline
Hardware: All
OS: All
medium
medium
Target Milestone: ---
Assignee: Anoop C S
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-15 14:59 UTC by Anoop C S
Modified: 2018-08-29 03:35 UTC (History)
3 users (show)

Fixed In Version: glusterfs-4.1.3 (or later)
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-29 03:35:40 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Anoop C S 2015-12-15 14:59:24 UTC
Changes from commit 79db3aced2ffca84a696192343d5b811833eb671 were done in an attempt to avoid lock upgrade/downgrade problems for a conflicting F_SETLKW lock request as explained below.

Consider the following sequence of events acting upon a file:
    1. App1 requests shared blocking byte range lock request
       from offset 0 to 5 and is granted.
    2. App2 requests shared blokcing byte range lock request
       from offset 0 to 5 and is granted.
    3. App1 requests exclusive blocking byte range lock request
       from offset 0 to 5 and is blocked.

Before the specified commit hash eventhough App2 releases its lock, App1's blocked lock request could not be granted due to lack of lock owner and related checks inside first_overlap() which is invoked from grant_blocked_locks() as soon as the release happens from App2. This undefined wait/hang was fixed via the commit in such a way that we unlock App1's previously held lock as soon as we receive a blocking lock request from App1 which conflicts with App2's lock. This would mean that we break the promise of granted shared lock given to App1 temporarily. pl_send_prelock_unlock() implements this early unlock.

Comment 1 Vijay Bellur 2015-12-15 15:02:42 UTC
REVIEW: http://review.gluster.org/12974 (features/locks: Handle blocking lock requests properly) posted (#1) for review on master by Anoop C S (anoopcs@redhat.com)

Comment 2 Vijay Bellur 2015-12-17 08:36:27 UTC
REVIEW: http://review.gluster.org/12974 (features/locks: Handle blocking lock requests properly) posted (#2) for review on master by Anoop C S (anoopcs@redhat.com)

Comment 3 Vijay Bellur 2015-12-18 06:16:38 UTC
REVIEW: http://review.gluster.org/12974 (features/locks: Handle blocking lock requests properly) posted (#3) for review on master by Anoop C S (anoopcs@redhat.com)

Comment 4 Vijay Bellur 2016-02-05 05:47:49 UTC
REVIEW: http://review.gluster.org/12974 (features/locks: Handle blocking lock requests properly) posted (#4) for review on master by Anoop C S (anoopcs@redhat.com)

Comment 5 Raghavendra G 2016-02-12 06:09:39 UTC
There are some test scripts at: https://bugzilla.redhat.com/show_bug.cgi?id=GLUSTER-1017

Can you check whether this patch passes all those tests?

Comment 6 Anoop C S 2016-02-19 05:32:13 UTC
Please my replies to the following patch posted upstream:

http://review.gluster.org/#/c/12974/

Comment 7 Mike McCune 2016-03-28 22:15:42 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 8 Vijay Bellur 2016-06-13 08:59:17 UTC
REVIEW: http://review.gluster.org/12974 (features/locks: Handle blocking lock requests properly) posted (#5) for review on master by Anoop C S (anoopcs@redhat.com)

Comment 9 Amar Tumballi 2018-08-29 03:35:40 UTC
This update is done in bulk based on the state of the patch and the time since last activity. If the issue is still seen, please reopen the bug.


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