Il 28-02-2018 18:07 Darrick J. Wong ha scritto:
reflink performs (more or less) a fdatasync of the source and dest file
before it starts so that any dirty pages backed by delayed allocation
reservation will be allocated and written to disk, but it doesn't do
the
"force all dirty metadata out to log" action that distinguishes
fdatasync from fsync. That is a deliberate design decision because:
1) fsync is fairly heavyweight,
2) customers might have disposable environments where it is preferable
to lose srcfile and destfile over paying performance penalties
all the time, and
3) if you need srcfile to be completely stable on disk, you needed to
call fsync anyway, and nothing prevents you from doing so before
calling copy_file_range/clone_file_range if that is part of your
operational requirements.
In other words, if at a certain point you can't afford to lose the
source file due to a host crash, you have to call fsync, as has been
the
case for ages. reflink does not itself call fsync, nor does it
increase
the chances of losing any file contents that weren't fsync'd before the
host went down.
Ok, this is exactly what I expect.
To add some context: Qemu/KVM added safe barrier/fsync passing years
ago, so when a guest issues a fsync+barrier operation (ie: after key
operations, as a journal update or a COMMIT) they are immediately passed
to the host, which issues real fsync+barrier on the backing file. In
other words, host's writeback cache is used as the volatile disk's DRAM
cache (which needs to be flushed at specific interval). See:
https://www.static.linuxfound.org/jp_uploads/JLS2009/jls09_hellwig.pdf
Back to the original argument: are guest/user initiated fsyncs+barriers
honored even *during a cp --reflink copy*? If so, I can't see any
shortcoming in using reflinking to hot copy a busy file. Sure, I risk
losing async writes (which are in writeback host cache *or* in the
unflushed volatile disk's DRAM cache), but this is nothing more (or
less) than a normal, interrupted copy. I am right saying that?
Maybe encapsulating the reflink copy in between two fsync calls is a
good idea?
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
