[Bugs] [Bug 1228160] linux untar hanged after the bricks are up in a 8+4 config

bugzilla at redhat.com bugzilla at redhat.com
Sun Jun 7 05:36:31 UTC 2015


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



--- Comment #3 from Anand Avati <aavati at redhat.com> ---
COMMIT: http://review.gluster.org/11084 committed in release-3.7 by Vijay
Bellur (vbellur at redhat.com) 
------
commit 6fce83e55c2a4b96de8c9b1ce5b1bc8a60eaacc3
Author: Pranith Kumar K <pkarampu at redhat.com>
Date:   Thu Jun 4 09:52:51 2015 +0530

    cluster/ec: EC_XATTR_DIRTY doesn't come in response

             Backport of http://review.gluster.com/11078

    Problem:
    ec_update_size_version expects all the keys it did xattrop with to come in
    response so that it can set the values again in
ec_update_size_version_done.
    But EC_XATTR_DIRTY is not combined so the value won't be present in the
    response. So ctx->post/pre_dirty are not updated in
    ec_update_size_version_done. So these values are still non-zero. When
    ec_unlock_now is called as part of flush's unlock phase it again tries to
    perform same xattrop for EC_XATTR_DIRTY. But ec_update_size_version is not
    expected to be called in unlock phase of flush because
ec_flush_size_version
    should have reset everything to zero and unlock is never invoked from
    ec_update_size_version_done for flush/fsync/fsyncdir. This leads to stale
lock
    which leads to hang.

    Fix:
    EC_XATTR_DIRTY is removed in ex_xattrop_cbk and is never combined with
other
    answers. So remove handling of this in the response.

    BUG: 1228160
    Change-Id: I657efca6e706e7acb541f98f526943f67562da9f
    Signed-off-by: Pranith Kumar K <pkarampu at redhat.com>
    Reviewed-on: http://review.gluster.org/11084
    Reviewed-by: Xavier Hernandez <xhernandez at datalab.es>
    Tested-by: Gluster Build System <jenkins at build.gluster.com>
    Tested-by: NetBSD Build System <jenkins at build.gluster.org>

-- 
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