Re: [PATCH qemu 4/4] qemu-img: convert: flush target image after copying

[Eric Blake <eblake@redhat.com>]

On Wed, Sep 30, 2026 at 03:19:25PM +0200, Fiona Ebner wrote:
> With 'qemu-img convert', when using a cache mode with 'cache.no-flush
> = off', the expectation is that the data is flushed to the disk, which
> happens since commit 80ccf93b88 ("qemu-img: let 'qemu-img convert'
> flush data"). This expectation also encompasses that failure to do so
> is properly reported, so ensure that 'qemu-img convert' exits with a
> non-zero status code when the target image cannot be flushed.
> 
> In particular, the reproducer below [0], based on a report by
> Ing. Alfonso Kuen Arroyo [1], would result in
> > rc=0
> > Content mismatch at offset XYZ!
> before this change, and in
> > rc=1
> > Content mismatch at offset XYZ!
> after this change.
> 
> Note that this change does not affect the (default) 'unsafe' cache
> mode, because bdrv_co_flush() still skips flush to disk for that cache
> mode.

Should we rethink the default? I get that during a long-running
qemu-img convert, it makes sense to avoid intermediate calls to flush
(the destination image is not going to be in use by a guest until the
qemu-img process completes, so there is no need to slow down the
conversion). But should we have a mode of operation where we guarantee
that we flush before exiting qemu-img, while ginoring all other flush
points in the middle (in between an explicit request for all
intermediate flushes to be acted on, vs. an explicit request to not do
any flushing at all), as as safer default going forward? That way, you
have to explicitly opt in to a case where qemu-img convert might
produce a corrupted copy due to an undiagnosed flush failure.

But I think that question can be deferred to another day - this patch
has merit of adding diagnosis for the setup of anyone explicitly
requesting flush safety of some sort, even if it doesn't change
behavior for the defaults when the user did not make an explicit flush
request.

Reviewed-by: Eric Blake <eblake@redhat.com>

This series caught my eyes because of the scenario you mentioned of an
NBD connection dying before a flush can finalize; so I'm planning on
queuing it through my NBD tree shortly.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org