Bug 984591

Summary:	Dist-geo-rep : renames to files will be synced as a new files without actually renaming on slave side by first xsync crawl.
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Vijaykumar Koppad <vkoppad>
Component:	geo-replication	Assignee:	Bug Updates Notification Mailing List <rhs-bugs>
Status:	CLOSED EOL	QA Contact:	shilpa <smanjara>
Severity:	high	Docs Contact:
Priority:	low
Version:	2.1	CC:	avishwan, chrisw, csaba, david.macdonald, rhs-bugs, rwheeler, surs, vagarwal
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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:
Bug Depends On:
Bug Blocks:	957769

Description Vijaykumar Koppad 2013-07-15 14:05:14 UTC

Description of problem: If files which were synced to slave are renamed after stopping the geo-rep session, and geo-rep starts , the first xsync crawl will sync those renamed files as new files to slave without actually renaming the slaves. If 100 files were renamed , you would get 200 files on the slave side. 


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


How reproducible: Consitently 


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. rename   all the files, using the command ./crefi.py -n 10 --multi -b 10 -d 10 --random --max=500K --min=10 --fop=rename <MNT_PNT>
6. start the geo-rep session. 
7. Check the number of files on master and slave. 

Actual results:  renames to files will be synced as a new files without actually renaming on slave side by first xsync crawl.


Expected results: if renames are done on master, it should be renames on the slaves too.


Additional info:

Comment 2 Amar Tumballi 2013-08-01 10:24:34 UTC

the first sync is intended to get the data on master to slave and anything after that is captured in 'changelog' and then only we are able to capture all the fops. Currently expected behavior, and behavior was same with earlier implementation.

Comment 8 Aravinda VK 2015-11-25 08:50:31 UTC

Closing this bug since RHGS 2.1 release reached EOL. Required bugs are cloned to RHGS 3.1. Please re-open this issue if found again.

Comment 9 Aravinda VK 2015-11-25 08:51:54 UTC

Closing this bug since RHGS 2.1 release reached EOL. Required bugs are cloned to RHGS 3.1. Please re-open this issue if found again.