On Tue, Feb 27, 2018 at 09:06:25AM +0100, Gionatan Danti wrote: > On 27/02/2018 01:33, Dave Chinner wrote: > >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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
