[Bugs] [Bug 1219412] Geo-Replication - Fails to handle file renaming correctly between master and slave

[bugzilla at redhat.com]

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



--- Comment #7 from Anand Avati <aavati at redhat.com> ---
COMMIT: http://review.gluster.org/10633 committed in release-3.7 by Vijay
Bellur (vbellur at redhat.com) 
------
commit c466b137b0cabb844ce7a1f92549ff9b72369830
Author: Saravanakumar Arumugam <sarumuga at redhat.com>
Date:   Tue May 5 17:03:39 2015 +0530

    geo-rep: rename handling in dht volume(changelog changes)

    Background:

    Glusterfs changelogs are stored in each brick, which records the changes
    happened in that brick. Georep will run in all the nodes of master and
processes
    changelogs "independently".  Processing changelogs is in brick level, but
    all the fops will be replayed on "slave mount" point.

    Problem:

    With a DHT volume, in changelog "internal fops" are NOT recorded.
    For Rename case, Rename is recorded in "hashed" brick changelog.
    (DHT's internal fops like creating linkto file, unlink is NOT recorded).
    This lead us to inconsistent rename operations.

    For example,
    Distribute volume created with Two bricks B1, B2.

    //Consider master volume mounted @ /mnt/master and following operations
    executed:
    cd /mnt/master
    touch f1 // f1 falls on B1 Hash
    mv f1 f2 // f2 falls on B2 Hash

    // Here, Changelogs are recorded as below:
    @B1
    CREATE f1

    @B2
    RENAME f1 f2

    Here, race exists between Brick B1 and B2, say B2 will get executed first.
    Source file f1 itself is "NOT PRESENT", so it will go ahead and create
    f2 (Current implementation).

    We have this problem When rename falls in another brick and
    file is unlinked in Master.

    Similar kind of issue exists in following case too(multiple rename):
    CREATE f1
    RENAME f1 f2
    RENAME f2 f1

    Solution:

    Instead of carrying out "changelogging" at "HASHED volume",
    carry out  at the "CACHED volume".
    This way we have rename operations carried out where actual files are
present.

    So,Changelog recorded as :
    @B1
    CREATE f1
    RENAME f1 f2

    Note:
    This patch is dependent on dht changes from this patch.
    http://review.gluster.org/10410/
    changelog related changes are separated out for review.

    In changelog, xdata passed from DHT is considered as:

    1. In case of unlink (internal operation as part of rename), xdata value
    is set , it is considered as RENAME and recorded accordingly.
    2. In case of rename (Hash and Cache different), xdata value is NOT
    set, recording rename operation is SKIPPED.

    BUG: 1219412
    Change-Id: I7691166c84991482b2cfe073df64e2317c935b13
    Reviewed-On: http://review.gluster.org/#/c/10220/
    Signed-off-by: Saravanakumar Arumugam <sarumuga at redhat.com>
    Reviewed-on: http://review.gluster.org/10633
    Reviewed-by: Aravinda VK <avishwan at redhat.com>
    Tested-by: Gluster Build System <jenkins at build.gluster.com>
    Reviewed-by: Vijay Bellur <vbellur 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.