[Bugs] [Bug 1408712] with granular-entry-self-heal enabled i see that there is a gfid mismatch and vm goes to paused state after migrating to another host

[bugzilla at redhat.com]

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



--- Comment #3 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: http://review.gluster.org/16286 committed in master by Pranith Kumar
Karampuri (pkarampu at redhat.com) 
------
commit da5ece887c218a7c572a1c25925a178dbd08d464
Author: Krutika Dhananjay <kdhananj at redhat.com>
Date:   Mon Dec 26 21:08:03 2016 +0530

    cluster/afr: Fix missing name indices due to EEXIST error

    PROBLEM:
    Consider a volume with  granular-entry-heal and sharding enabled. When
    a replica is down and a shard is created as part of a write, the name
    index is correctly created under indices/entry-changes/<dot-shard-gfid>.
    Now when a read on the same region triggers another MKNOD, the fop
    fails on the online bricks with EEXIST. By virtue of this being a
    symmetric error, the failed_subvols[] array is reset to all zeroes.
    Because of this, before post-op, the GF_XATTROP_ENTRY_OUT_KEY will be
    set, causing the name index, which was created in the previous MKNOD
    operation, to be wrongly deleted in THIS MKNOD operation.

    FIX:
    The ideal fix would have been for a transaction to delete the name
    index ONLY if it knows it is the one that created the index in the first
    place. This would involve gathering information as to whether THIS xattrop
    created the index from individual bricks, aggregating their responses and
    based on the various posisble combinations of responses, decide whether to
    delete the index or not. This is rather complex. Simpler fix would be
    for post-op to examine local->op_ret in the event of no failed_subvols
    to figure out whether to delete the name index or not. This can
occasionally
    lead to creation of stale name indices but they won't be affecting the IO
path
    or mess with pending changelogs in any way and self-heal in its crawl of
    "entry-changes" directory would take care to delete such indices.

    Change-Id: Ic1b5257f4dc9c20cb740a866b9598cf785a1affa
    BUG: 1408712
    Signed-off-by: Krutika Dhananjay <kdhananj at redhat.com>
    Reviewed-on: http://review.gluster.org/16286
    Smoke: Gluster Build System <jenkins at build.gluster.org>
    Reviewed-by: Pranith Kumar Karampuri <pkarampu at redhat.com>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster 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=TqcuLAMrxc&a=cc_unsubscribe