Bug 1709734

Summary:	Geo-rep: Data inconsistency while syncing heavy renames with constant destination name
Product:	[Community] GlusterFS	Reporter:	Kotresh HR <khiremat>
Component:	geo-replication	Assignee:	Kotresh HR <khiremat>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6	CC:	bugs
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-17 07:48:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kotresh HR 2019-05-14 08:39:26 UTC

This bug was initially created as a copy of Bug #1694820

I am copying this bug because: 



Description of problem:

This problem only exists in heavy RENAME workload where parallel rename are frequent or doing RENAME with existing destination.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Run frequent RENAME on master mount and check for sync in slave.

Ex - while true; do uuid="`uuidgen`"; echo "some data" > "test$uuid"; mv "test$uuid" "test" -f; done 

Actual results:

Does not syncs renames properly and creates multiples files in slave.

Expected results:
Should sync renames.

Comment 1 Worker Ant 2019-05-14 08:52:24 UTC

REVIEW: https://review.gluster.org/22723 (geo-rep: Fix rename with existing destination with same gfid) posted (#1) for review on release-6 by Kotresh HR

Comment 2 Worker Ant 2019-05-17 07:48:58 UTC

REVIEW: https://review.gluster.org/22723 (geo-rep: Fix rename with existing destination with same gfid) merged (#2) on release-6 by Amar Tumballi