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@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
