Bug 984471 - Dist-geo-rep : geo-rep with change_detector xsync or first xsync crawl , fails to sync few of the regular files to the slave.
Dist-geo-rep : geo-rep with change_detector xsync or first xsync crawl , fail...
Status: CLOSED ERRATA
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: geo-replication (Show other bugs)
2.1
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Venky Shankar
Vijaykumar Koppad
: TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-15 06:28 EDT by Vijaykumar Koppad
Modified: 2014-08-24 20:50 EDT (History)
9 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0.12rhs.beta6-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-23 18:29:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vijaykumar Koppad 2013-07-15 06:28:58 EDT
Description of problem: After start of a geo-rep session, if first xsync crawl gets hardlinks to sync to slave, it fails to sync all the files to the slave. 

If xsync is not capable of syncing hardlinks as hardlinks, it should either sync all the hardlinks separate files or it shouldn't handle hardlinks at all. It shouldn't sync inconsistent number of hardlinks to slaves which mismatch with the master.

Observations : The files which were missing from slave had no entry in the XSYNC-CHANGELOGs   on the master. Which means xsync has failed to get the entry. This could be a problem with regular files also (but I haven't hit anything like that so far).  


Version-Release number of selected component (if applicable):3.4.0.12rhs.beta4-1.el6rhs.x86_64


How reproducible: Inconsistent


Steps to Reproduce:
1.Create and start a geo-rep relationship between master(DIST-REP) and slave. 
2.Create files using the command, ./crefi.py -n 10 --multi -b 10 -d 10 --random --max=500K --min=10 <MNT_PNT>
3.Let it sync to slave.
4. Stop the geo-rep session,
5. create hardlinks to all the files, using the command ./crefi.py -n 10 --multi -b 10 -d 10 --random --max=500K --min=10 --fop=hardlink <MNT_PNT>
6. start the geo-rep session. 
7. Check if it has completed syncing by checking the number of files on master and slave.

Actual results:It fails to sync all the hardlinks to slave. 


Expected results: Either it should sync all the hardlinks or it shouldn't sync it at all.


Additional info:
Comment 1 Venky Shankar 2013-07-15 06:52:04 EDT
xsync crawl would get the list of the files that were created and would try to create them on the slave (it does not know if it's a hardlink). This file would have a gfid already existing on the slave with a different parent-gfid/bname.

Could you check if the entries are present in the XSYNC-CHANGELOG.<timestamp> file?
Comment 3 Vijaykumar Koppad 2013-07-15 07:28:02 EDT
Venky,
  
    The missing files have entries in XSYNC-CHANGELOG.<timestamp>. I was checking it wrongly earlier.

This is not the case with hard links. It happens with the regular file creation too. Stop geo-rep, create some 1000  regular files, and start geo-rep. It fails to sync all the files to slave.
Comment 8 Vijaykumar Koppad 2013-08-01 05:49:45 EDT
verified on 3.4.0.14rhs-1.el6rhs.x86_64
Comment 9 Scott Haines 2013-09-23 18:29:51 EDT
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. 

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1262.html

Note You need to log in before you can comment on or make changes to this bug.