Red Hat Bugzilla – 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.
Last modified: 2014-08-24 20:50:12 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:
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?
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.
verified on 3.4.0.14rhs-1.el6rhs.x86_64
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