Bug 1463628 - file renames can lead to duplicate entries during a conservative merge which also means two files having same gfids
file renames can lead to duplicate entries during a conservative merge which ...
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: replicate (Show other bugs)
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Ravishankar N
: ZStream
Depends On:
  Show dependency treegraph
Reported: 2017-06-21 07:26 EDT by nchilaka
Modified: 2017-11-28 05:32 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-11-28 05:32:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description nchilaka 2017-06-21 07:26:01 EDT
Description of problem:
I hit this bug while working on different scenarios to verify 1437773 - Undo pending xattrs only on the up bricks 
(note that this has NOTHING to do with the above fix ie it is NOT A regression by the above fix)

When we do a rename of an existing file when one brick is down and again do a rename of the same old file when the previous offline brick comes up and the online one goes down, a conservative merge can lead to both the rename entries existing on the storage.

This means two files for same data. However I don't see any storage space impact as both files are having same inode , meaning they are mimicing hardlinks.
The problem is inconvenience and confusion for the end users and unncessary hardlinks created

Should be a day1 bug

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

How reproducible:

Steps to Reproduce:
1.create 1x2 volume b1 and b2 are replicas
2.create file f1
3.bring down b1 and rename f1->fx1
4. bring down b2 and bring up b1
5. rename f1->fy1
6. bring up b2
7. wait for heal to complete

Actual results:
on mount we can see both fx1 and fy1 and both obviously have same gfids

Expected results:
need to handle such rename cases
Comment 2 nchilaka 2017-06-21 07:26:44 EDT
can see this even with 1x3, but obviously set quorum as none
Comment 6 Ravishankar N 2017-11-28 05:32:26 EST
Closing based on comment #4 since the impact is just 'data gain' (as opposed to data-loss) due to extra hard links being created as a part of self-heal process.

Note You need to log in before you can comment on or make changes to this bug.