[Bugs] [Bug 1422819] New: [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=1422819

            Bug ID: 1422819
           Summary: [Geo-rep] Recreating geo-rep session with same slave
                    after deleting with reset-sync-time fails to sync
           Product: GlusterFS
           Version: 3.10
         Component: geo-replication
          Assignee: bugs at gluster.org
          Reporter: khiremat at redhat.com
                CC: bugs at gluster.org
        Depends On: 1422760
            Blocks: 1422811, 1422818



+++ This bug was initially created as a clone of Bug #1422760 +++

Description of problem:
When geo-rep session is deleted with the option reset-sync-time and the data on
slave is deleted, the recreation of session with same old slave volume is not
syncing data from master to slave. It is observed, it happens only if the data
to slave is synced via xsync before deletion of the geo-rep session. Only
entries under root are being synced.

Version-Release number of selected component (if applicable):
mainline

How reproducible:
Always

Steps to Reproduce:
1.  Create geo-rep session between 'master' and 'slave' volume.
2.  Set change-detector to 'xsync'
3.  Create data on master and let it sync to slave
4.  Delete geo-rep session with 'reset-rsync-time'
5.  Delete data on slave volume.
6.  Recreate geo-rep session with same master and slave volume
7.  Start the geo-rep

Actual results:
Only first level entries under root are being synced and rest are not synced.

Expected results:
It is expected all the data from master is synced again.

Additional info:

--- Additional comment from Kotresh HR on 2017-02-16 00:53:46 EST ---

Patch posted: https://review.gluster.org/#/c/16629/1

--- Additional comment from Worker Ant on 2017-02-16 00:58:48 EST ---

REVIEW: https://review.gluster.org/16629 (geo-rep: Fix xsync crawl) posted (#2)
for review on master by Kotresh HR (khiremat at redhat.com)

--- Additional comment from Worker Ant on 2017-02-16 02:50:35 EST ---

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>


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1422760
[Bug 1422760] [Geo-rep] Recreating geo-rep session with same slave after
deleting with reset-sync-time fails to sync
https://bugzilla.redhat.com/show_bug.cgi?id=1422811
[Bug 1422811] [Geo-rep] Recreating geo-rep session with same slave after
deleting with reset-sync-time fails to sync
https://bugzilla.redhat.com/show_bug.cgi?id=1422818
[Bug 1422818] [Geo-rep] Recreating geo-rep session with same slave after
deleting with reset-sync-time fails to sync
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.