Re: Reflink (cow) copy of busy files

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

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