On Tue, Feb 27, 2018 at 09:06:25AM +0100, Gionatan Danti wrote:

On 27/02/2018 01:33, Dave Chinner wrote:

quoted

On Mon, Feb 26, 2018 at 09:26:01AM -0800, Darrick J. Wong wrote:

My point is that vfs_clone_file_range is not running fsync(2)i
operations.

It's a fdatawrite_and_wait() call, which submits dirty data to disk
and waits for it, but does *not flush volatile storage caches*.
IOWs, it's not a data integrity operation.

Hence while the reflink now has "data on disk" and can clone the
extents, Neither the data nor the extents being cloned are stable
and won't be until an fsync operation is performed on either the
reflink source or destination file....

Still no cache flushes. Hence even after the clone has run,
you can still lose the data (and extents!) from the host file....

Am I right saying that you are speaking about an *host* crash during
or just after the clone?

Even in such a case, only the newly created file clone should be
lost/corrupted, while the original file will *not* be affected,
right? Or will an interrupted clone operation (ie: due to a power
failure) leave *both* files in an unconsistent state?

A host crash can lose data from the original file when it is
configured in writeback mode (as you've said you are using). If the
clone is there, both source and clone should be fully intact. If
it's not, then you will have lost data from the original image file.

But, really, why risk losing data or filesystem corruption by trying
to take shortcuts?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com