Red Hat Bugzilla – Bug 414451
mv should call fsync() on copied file before unlinking original
Last modified: 2014-06-18 03:37:05 EDT
Opening this as a RHEL5.1 bug, but it's actually an upstream problem as well...
This was brought to my attention as a result of working on bug 329431. In that
case, CIFS had a bug where write failures were not being properly reported at
fsync or close, and this was causing mv to think that it had successfully copied
the file. It would then delete the original even though the new file wasn't
successfully written out.
While fixing mv wouldn't have worked around that bug, mv should be doing a fsync
on the new file that it writes out before closing it to ensure that it has
actually been committed to the device. It appears to check the return val on
close(), but that's not always reliable. From close(2) manpage:
A successful close does not guarantee that the data has been success-
fully saved to disk, as the kernel defers writes. It is not common for
a filesystem to flush the buffers when the stream is closed. If you
need to be sure that the data is physically stored use fsync(2). (It
will depend on the disk hardware at this point.)
It seems like it would be safest to have mv call an explicit fsync() when
copying a file to make sure that it has actually been written out.
Thanks for the suggestion.
imho, mv/cp should not call fsync before close by default. However, if you
think of this as a feature request, you're not the first. Adding --atomic or
--fsync-before-close options (two separate things) to programs like mv and cp
might be worth doing. This has been brought up before. See the discussion here
or the Debian bug that prompted the thread: http://bugs.debian.org/322457
Regarding close not reporting write failure, that's true, and it would be safer
always to call fsync when mv has to resort to copying (rather than the usual
rename), but you would not like the performance impact. Calling fsync or
fdatasync is like applying a very big hammer (think cartoon-sized ;-), and is
rarely appropriate. If with CIFS, one cannot rely on close to detect the usual
ENOSPC-style errors, then *many* applications will end up misbehaving...
If you're interested in pursuing the option-adding idea, please raise the issue
upstream, on email@example.com.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.