Il 25-02-2018 22:13 Dave Chinner ha scritto:
This isn't a copy on write issue. This is an issue of the state of the file and the I/O stack above it at the time the data extents are shared. There is I/O inflight, and so there's no guarantee that what is in the extents being shared is consistent. Freezing the filesystem stops IO in flight, so the extents can be shared while the filesystem knows it has consistent state on stable storage.
Uhm, it seems the very same definition/catches of "crash-consistent" snapshot...
Suppose an XFS filesystem used for VM disk images hosting, with running VMs. I naively execute a cp --reflink=always copy, stop the original VM and start the copied one.
For an atomic snapshot I would expect that dataloss is comparable to a "power pull" case: - async writes are lost. After all, they were on the pagecache and never hit the backing file; - unacknowledged sync writes are lost. Again, they never successfully hit the disk; - acknowledged sync writes (ie: the one which returned) are properly written to the backing file.
If the above is correct, when starting the new (copied) VM, the guest filesystem will behave as power was lost: its journal will be replied and broght to a consistent state. Application can/will be affected based on what they were doing at the time of the reflinked copy, but important ones (ie: the ones correctly using fsync), as databases, will gracefully recover replying their logs.
This should be similar to how LVM snapshot works when no filesystem is (directly) layered on top of the volume (ie: volume assigned to a VM).
Still, you warned be that a CoW copy on a running VM will produce garbage; so I am surely misunderstanding something.
I would greatly appreciate any clarification. Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx GPG public key ID: FF5F32A8 -- 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
