Bug 984471

Summary:	Dist-geo-rep : geo-rep with change_detector xsync or first xsync crawl , fails to sync few of the regular files to the slave.
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Vijaykumar Koppad <vkoppad>
Component:	geo-replication	Assignee:	Venky Shankar <vshankar>
Status:	CLOSED ERRATA	QA Contact:	Vijaykumar Koppad <vkoppad>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	2.1	CC:	aavati, amarts, bbandari, csaba, racpatel, rhs-bugs, sdharane, shaines, vbhat
Target Milestone:	---	Keywords:	TestBlocker
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
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 22:29:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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