[Bugs] [Bug 1462121] [GNFS+EC] Unable to release the lock when the other client tries to acquire the lock on the same file

bugzilla at redhat.com bugzilla at redhat.com
Mon Jun 19 15:49:54 UTC 2017


https://bugzilla.redhat.com/show_bug.cgi?id=1462121



--- Comment #3 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/17556 committed in release-3.11 by
Shyamsundar Ranganathan (srangana at redhat.com) 
------
commit 6e377faf4490f20a63634c8baecb76886c0dac8a
Author: Pranith Kumar K <pkarampu at redhat.com>
Date:   Tue Jun 13 23:35:40 2017 +0530

    cluster/ec: lk shouldn't be a transaction

    Problem:
    When application sends a blocking lock, the lk fop actually waits under
    inodelk.  This can lead to a dead-lock.
    1) Let's say app-1 takes exculsive-fcntl-lock on the file
    2) app-2 attempts an exclusive-fcntl-lock on the file which goes to
blocking
       stage note: app-2 is blocked inside transaction which holds an
inode-lock
    3) app-1 tries to perform write which needs inode-lock so it gets blocked
on
       app-2 to unlock inodelk and app-2 is blocked on app-1 to unlock
fcntl-lock

    Fix:
    Correct way to fix this issue and make fcntl locks perform well would be to
    introduce
    2-phase locking for fcntl lock:
    1) Implement a try-lock phase where locks xlator will not merge lk call
with
       existing calls until a commit-lock phase.
    2) If in try-lock phase we get quorum number of success without any EAGAIN
       error, then send a commit-lock which will merge locks.
    3) In case there are any errors, unlock should just delete the lock-object
       which was tried earlier and shouldn't touch the committed locks.

    Unfortunately this is a sizeable feature and need to be thought through for
any
    corner cases.  Until then remove transaction from lk call.

     >BUG: 1455049
     >Change-Id: I18a782903ba0eb43f1e6526fb0cf8c626c460159
     >Signed-off-by: Pranith Kumar K <pkarampu at redhat.com>
     >Reviewed-on: https://review.gluster.org/17542
     >Smoke: Gluster Build System <jenkins at build.gluster.org>
     >NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
     >CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
     >Reviewed-by: Ashish Pandey <aspandey at redhat.com>
     >Reviewed-by: Xavier Hernandez <xhernandez at datalab.es>

    BUG: 1462121
    Change-Id: I18a782903ba0eb43f1e6526fb0cf8c626c460159
    Signed-off-by: Pranith Kumar K <pkarampu at redhat.com>
    Reviewed-on: https://review.gluster.org/17556
    Smoke: Gluster Build System <jenkins at build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    Reviewed-by: Shyamsundar Ranganathan <srangana at redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list