Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1709734

Summary: Geo-rep: Data inconsistency while syncing heavy renames with constant destination name
Product: [Community] GlusterFS Reporter: Kotresh HR <khiremat>
Component: geo-replicationAssignee: Kotresh HR <khiremat>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6CC: 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