[Bugs] [Bug 1422760] [Geo-rep] Recreating geo-rep session with same slave after deleting with reset-sync-time fails to sync

[bugzilla at redhat.com]

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



--- Comment #3 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/16629 committed in master by Aravinda VK
(avishwan at redhat.com) 
------
commit 267578ec0d6b29483a1bd402165ea8c388ad825e
Author: Kotresh HR <khiremat at redhat.com>
Date:   Wed Feb 15 03:44:17 2017 -0500

    geo-rep: Fix xsync crawl

    If stime is set to (0, 0) on master brick root, it
    is expected to do complete sync ignoring the stime
    set on sub directories. But while initializing the
    stime variable for comparison, it was initailized
    to (-1, 0) instead of (0, 0). Fixed the same.

    The stime is set to (0, 0) with the 'reset-sync-time' option
    while deleting session.

    'gluster vol geo-rep master fedora1::slave delete reset-sync-time'

    The scenario happens when geo-rep session is deleted as above and
    for some reason the session is re-established with same slave volume
    after deleting data on slave volume.

    Change-Id: Ie5bc8f008dead637a09495adeef5577e2b33bc90
    BUG: 1422760
    Signed-off-by: Kotresh HR <khiremat at redhat.com>
    Reviewed-on: https://review.gluster.org/16629
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
    Smoke: Gluster Build System <jenkins at build.gluster.org>
    Reviewed-by: Aravinda VK <avishwan at redhat.com>

-- 
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=SIJaMudT8n&a=cc_unsubscribe