[Bugs] [Bug 1355609] [granular entry sh] - Clean up (stale) directory indices in the event of an `rm -rf` and also in the normal flow while a brick is down

bugzilla at redhat.com bugzilla at redhat.com
Fri Jul 15 07:03:16 UTC 2016


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



--- Comment #6 from Vijay Bellur <vbellur at redhat.com> ---
COMMIT: http://review.gluster.org/14896 committed in release-3.8 by Pranith
Kumar Karampuri (pkarampu at redhat.com) 
------
commit 05dacf07b4d427aa144aacb730e2296d9f96fe6a
Author: Krutika Dhananjay <kdhananj at redhat.com>
Date:   Wed Jun 22 14:52:58 2016 +0530

    features/index: Delete parent dir indices when heal on it is complete

            Backport of: http://review.gluster.org/#/c/14781

    In this patch, the state information about whether a directory
    gfid index is present or not is stored in the inode ctx with
    values IN and NOTIN. This saves index xl the need to perform
    stat() everytime an index_entry_create() is called.

    When a brick is restarted these in-memory inode ctx records will
    be gone. So when granular entry heal happens after a brick is restarted,
    and a post-op is done on the parent, if the state gotten from inode ctx
    is UNKNOWN, then index xl does a stat to initialize the state as IN or
    NOTIN. Note that this is a one-time operation for the lifetime of the
    brick. Such a change also helps avoid calling index_del() in
    xattrop_index_action() periodically even when granular self-heal is
    disabled or when the volume type is disperse.

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


More information about the Bugs mailing list