Re: Reflink (cow) copy of busy files

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

Il 27-02-2018 23:04 Dave Chinner ha scritto:
> 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.

I have difficult grasping how a system crash during a cp --refcopy could 
corrupt the source file.
As per Darrick explanation, new writes on the original file should be 
blocked/queued during the copy. Even if this is not the case, fsync 
writes should complete only when data successfully landed on the disk 
platter. Losing some second on async writes should not be a problem in 
many environments (this is the very reasoning behind providing Qemu/KVM 
with a working writeback option).

Clearly a crash during the copy *will* produce an invalid destination 
file, but this can not be avoided (after all, the system crashed!).

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

Losing data and filesystem corruption are two *very* different things. 
On many VMs, I can afford losing some seconds of async writes; 
obviously, fsync writes (which can lead do filesystem corruption) must 
*not* be lost on *any* condition.

The point of the discussion is that if a cp --reflink is suitable for 
hot backup, it would be an extremely fast and convenient method to take 
"cheap" snapshot of key files. But if an interrupted copy can lead to 
total loss of the *original* file/filesystem, than this is clearly the 
wrong idea.

I am missing something?
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