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.
Summary: Dist-geo-rep : geo-rep with change_detector xsync or first xsync crawl , fail...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: geo-replication
Version: 2.1
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Venky Shankar
QA Contact: Vijaykumar Koppad
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-15 10:28 UTC by Vijaykumar Koppad
Modified: 2014-08-25 00:50 UTC (History)
9 users (show)

Fixed In Version: glusterfs-3.4.0.12rhs.beta6-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-23 22:29:51 UTC
Embargoed:


Attachments (Terms of Use)

Description Vijaykumar Koppad 2013-07-15 10:28:58 UTC
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 10:52:04 UTC
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 11:28:02 UTC
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 09:49:45 UTC
verified on 3.4.0.14rhs-1.el6rhs.x86_64

Comment 9 Scott Haines 2013-09-23 22:29:51 UTC
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.