Bug 1471309

Summary: non-atomic file move operation on same volume
Product: [Community] GlusterFS Reporter: Danny Couture <couture.danny>
Component: coreAssignee: bugs <bugs>
Status: CLOSED UPSTREAM QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: mainlineCC: bugs, pasik
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-12 12:31:46 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:
Attachments:
Description Flags
simple script trying to discover non-atomic move none

Description Danny Couture 2017-07-15 00:14:31 UTC
Created attachment 1298720 [details]
simple script trying to discover non-atomic move

Description of problem:
it is possible to see multiple intermediate state while moving a file over one that already exists even if both the source and the destination are on the same volume.

normally, on ext4, moving a file is an atomic operation where either the src file is present with uncorrupted readable content or the destination is present with uncorrupted readable content.

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

How reproducible: 
100%

Steps to Reproduce:
1. run the attached script twice in parallel on the same folder of the same gluster volume

Actual results:
multiple different results are currently possible

for a volume with a single brick, I get this error
md5sum: ./test: Operation not permitted
non atomic move!!! actual md5:  vs expected 0f343b0931126a20f133d67c2b018a3b

for a volume with multiple bricks using tcp transport, I get another error
md5sum: ./test: No such file or directory
non atomic move!!! actual md5:  vs expected 0f343b0931126a20f133d67c2b018a3b

Expected results:
same as ext4, no errors should ever happen, once created, the file should always exist since its only overwritten... and its content should either be the old content, or the new content, but not some intermediate state.

Comment 1 Amar Tumballi 2018-10-12 16:25:25 UTC
https://lists.gluster.org/pipermail/gluster-devel/2018-October/055488.html talks about the effort involved here!

Comment 3 Worker Ant 2020-03-12 12:31:46 UTC
This bug is moved to https://github.com/gluster/glusterfs/issues/900, and will be tracked there from now on. Visit GitHub issues URL for further details