Re: Reflink (cow) copy of busy files

[Gionatan Danti <g.danti@assyoma.it>]

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@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8