[Bugs] [Bug 1413062] [Arbiter] IO's Halted and heal info command hung

[bugzilla at redhat.com]

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



--- Comment #2 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: http://review.gluster.org/16413 committed in release-3.9 by Pranith
Kumar Karampuri (pkarampu at redhat.com) 
------
commit 042d4aaa55706332d5390d8ee01c6a747c6c3118
Author: Pranith Kumar K <pkarampu at redhat.com>
Date:   Mon Dec 5 13:20:51 2016 +0530

    cluster/afr: Remove backward compatibility for locks with v1

    When we have cascading locks with same lk-owner there is a possibility for
    a deadlock to happen. One example is as follows:

    self-heal takes a lock in data-domain for big name with 256 chars of
"aaaa...a"
    and starts heal in a 3-way replication when brick-0 is offline and healing
from
    brick-1 to brick-2 is in progress. So this lock is active on brick-1 and
    brick-2. Now brick-0 comes online and an operation wants to take full lock
and
    the lock is granted at brick-0 and it is waiting for lock on brick-1. As
part
    of entry healing it takes full locks on all the available bricks and then
    proceeds with healing the entry. Now this lock will start waiting on
brick-0
    because some other operation already has a granted lock on it. This leads
to a
    deadlock. Operation is waiting for unlock on "aaaa..." by heal where as
heal is
    waiting for the operation to unlock on brick-0. Initially I thought this is
    happening because healing is trying to take a lock on all the available
bricks
    instead of just the bricks that are participating in heal. But later
realized
    that same kind of deadlock can happen if a brick goes down after the heal
    starts but comes back before it completes. So the essential problem is the
    cascading locks with same lk-owner which were added for backward
compatibility
    with afr-v1 which can be safely removed now that versions with afr-v1 are
    already EOL. This patch removes the compatibility with v1 which requires
    cascading locks with same lk-owner.

    In the next version we can make locking-scheme option a dummy and switch
    completely to v2.

     >BUG: 1401404
     >Change-Id: Ic9afab8260f5ff4dff5329eb0429811bcb879079
     >Signed-off-by: Pranith Kumar K <pkarampu at redhat.com>
     >Reviewed-on: http://review.gluster.org/16024
     >Smoke: Gluster Build System <jenkins at build.gluster.org>
     >Reviewed-by: Ravishankar N <ravishankar at redhat.com>
     >NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
     >CentOS-regression: Gluster Build System <jenkins at build.gluster.org>

    BUG: 1413062
    Change-Id: I4f5d485d9e0646ad3dc384e5ec36682b0933c9d3
    Signed-off-by: Pranith Kumar K <pkarampu at redhat.com>
    Reviewed-on: http://review.gluster.org/16413
    Smoke: Gluster Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vdYvSu87kS&a=cc_unsubscribe