Bug 1471309 - non-atomic file move operation on same volume
Summary: non-atomic file move operation on same volume
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-15 00:14 UTC by Danny Couture
Modified: 2020-03-12 12:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-12 12:31:46 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)
simple script trying to discover non-atomic move (348 bytes, application/x-shellscript)
2017-07-15 00:14 UTC, Danny Couture
no flags Details

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


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