[Bugs] [Bug 1349274] New: [geo-rep]: If the data is copied from .snaps directory to the master, it doesn' t get sync to slave [First Copy]

[bugzilla at redhat.com]

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

            Bug ID: 1349274
           Summary: [geo-rep]: If the data is copied from .snaps directory
                    to the master, it doesn't get sync to slave [First
                    Copy]
           Product: GlusterFS
           Version: 3.8.0
         Component: geo-replication
          Keywords: ZStream
          Severity: urgent
          Assignee: bugs at gluster.org
          Reporter: khiremat at redhat.com
                CC: avishwan at redhat.com, bmohanra at redhat.com,
                    bugs at gluster.org, csaba at redhat.com,
                    rcyriac at redhat.com, rhinduja at redhat.com,
                    storage-qa-internal at redhat.com
        Depends On: 1344908, 1348904
            Blocks: 1349271



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

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

Description of problem:
=======================

In a scenario, where data is copied from the snapshot from .snaps directory
using (uss) to the master mount. The entries gets synced to slave but data
remains 0 in size. 

Master:
=======

[root at tia master]# cp -rf
/mnt/master/.snaps/geo_snap_multi_text_glusterfs_create_GMT-2016.06.12-07.26.06/thread0
.
[root at tia master]#

[root at tia master]# ls
thread0
[root at tia master]# 
[root at tia master]# cd thread0/
[root at tia thread0]# ls
level00  level01  level02
[root at tia thread0]# cd level00/
[root at tia level00]# ll
total 774
-rw-r--r--. 1 root root  81184 Jun 12  2016 575c5b2e%%179OT6LH9E
-rw-r--r--. 1 root root 189899 Jun 12  2016 575c5b2e%%8AKXW79FK8
-rw-r--r--. 1 root root 186345 Jun 12  2016 575c5b2e%%E4UB060CSR
-rw-r--r--. 1 root root 171280 Jun 12  2016 575c5b2e%%VGRDMPC2PL
-rw-r--r--. 1 root root 158768 Jun 12  2016 575c5b2e%%W7WO0PW4W9
drwxr-xr-x. 3 root root   4096 Jun 12  2016 level10
[root at tia level00]# 


Slave:
======

[root at tia slave]# ls
thread0
[root at tia slave]# cd thread0/
[root at tia thread0]# ls
level00  level01  level02
[root at tia thread0]# cd level00/
[root at tia level00]# ll
total 4
-rw-r--r--. 1 root root    0 Jun 12  2016 575c5b2e%%179OT6LH9E
-rw-r--r--. 1 root root    0 Jun 12  2016 575c5b2e%%8AKXW79FK8
-rw-r--r--. 1 root root    0 Jun 12  2016 575c5b2e%%E4UB060CSR
-rw-r--r--. 1 root root    0 Jun 12  2016 575c5b2e%%VGRDMPC2PL
-rw-r--r--. 1 root root    0 Jun 12  2016 575c5b2e%%W7WO0PW4W9
drwxr-xr-x. 3 root root 4096 Jun 12  2016 level10
[root at tia level00]# 


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


How reproducible:
=================
Always


Steps to Reproduce:
==================
1. Create geo-rep session between master and slave
2. Create data on Master volume
3. It will sync to slave
4. Pause the geo-rep session
5. Take a snapshot of Master volume
6. Start the geo-rep session
7. Remove the data from Master
8. Data will be removed from Slave too
9. Enable uss on Master
10. Activate the snapshot 
11. Copy back the data from .snaps/<snapshot> to master root
12. Entries gets created at slave but data doesn't sync


Actual results:
===============
Entries gets created at slave but data doesn't sync

Expected results:
=================
Data along with entries should also get sync to slave


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1344908
[Bug 1344908] [geo-rep]: If the data is copied from .snaps directory to the
master, it doesn't get sync to slave [First Copy]
https://bugzilla.redhat.com/show_bug.cgi?id=1348904
[Bug 1348904] [geo-rep]: If the data is copied from .snaps directory to the
master, it doesn't get sync to slave [First Copy]
https://bugzilla.redhat.com/show_bug.cgi?id=1349271
[Bug 1349271] [geo-rep]: If the data is copied from .snaps directory to the
master, it doesn't get sync to slave [First Copy]
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.