On Sat, Jul 10, 2021 at 09:06:24PM +0300, Nir Soffer wrote:
> On 7/9/21 6:39 PM, Eric Blake wrote:
> > Waiting until the end of the convert operation (a potentially
> > time-consuming task) to finally detect that we can't copy a bitmap is
> > bad, comparing to failing fast up front. Furthermore, this prevents
> > us from leaving a file behind with a bitmap that is not marked as
> > inconsistent even though it does not have sane contents.
>
> I don't think this is an issue since qemu-img terminate with non-zero
> exit code, and we cannot ensure that image is complete if we fail in
> the middle of the operation for all image formats and protocols.
>
> For files we could use a temporary file and rename after successful
> conversion for for raw format on block device we don't have any way
> to mark the contents as temporary.
Atomic rename into place for files is nice, but as you point out, it
doesn't help when targetting block devices. So whatever we do to keep
block devices robust even across temporary state changes is also
sufficient for files, even if we can indeed improve the situation for
files in a later patch.
>
> But failing fast is very important.
>
> > This fixes the problems exposed in the previous patch to the iotest.
> >
> > Signed-off-by: Eric Blake <ebl...@redhat.com>
> > ---
> > qemu-img.c | 30 +++++++++++++++++--
> > tests/qemu-iotests/tests/qemu-img-bitmaps | 2 --
> > tests/qemu-iotests/tests/qemu-img-bitmaps.out | 20 ++-----------
> > 3 files changed, 29 insertions(+), 23 deletions(-)
> >
> > diff --git a/qemu-img.c b/qemu-img.c
> > index 7956a8996512..e84b3c530155 100644
> > --- a/qemu-img.c
> > +++ b/qemu-img.c
> > @@ -2101,6 +2101,30 @@ static int convert_do_copy(ImgConvertState *s)
> > return s->ret;
> > }
> >
> > +/* Check that bitmaps can be copied, or output an error */
> > +static int convert_check_bitmaps(BlockDriverState *src)
> > +{
> > + BdrvDirtyBitmap *bm;
> > +
> > + if (!bdrv_supports_persistent_dirty_bitmap(src)) {
> > + error_report("Source lacks bitmap support");
> > + return -1;
> > + }
> > + FOR_EACH_DIRTY_BITMAP(src, bm) {
> > + const char *name;
> > +
> > + if (!bdrv_dirty_bitmap_get_persistence(bm)) {
> > + continue;
> > + }
> > + name = bdrv_dirty_bitmap_name(bm);
> > + if (bdrv_dirty_bitmap_inconsistent(bm)) {
> > + error_report("Cannot copy inconsistent bitmap '%s'", name);
>
> We can add a useful hint:
>
> Try "qemu-img bitmap --remove" to delete this bitmap from disk.
Yeah, that might be worthwhile.
>
> > + return -1;
> > + }
> > + }
> > + return 0;
> > +}
> > +
> > static int convert_copy_bitmaps(BlockDriverState *src, BlockDriverState
> > *dst)
> > {
> > BdrvDirtyBitmap *bm;
> > @@ -2127,6 +2151,7 @@ static int convert_copy_bitmaps(BlockDriverState
> > *src, BlockDriverState *dst)
> > &err);
> > if (err) {
> > error_reportf_err(err, "Failed to populate bitmap %s: ",
> > name);
> > + qmp_block_dirty_bitmap_remove(dst->node_name, name, NULL);
>
> This may fail for the same reason populate failed (e.g. storage became
> inaccessibel in the middle of the copy). Since we fail the convert, I don't
> think it worth to try to do this kind of cleanup.
>
> If we have a way to disable the bitmap before merge, and enable it after
> successful merge it make more sense, since if the operation fails we are
> left with disabled bitmap.
If we got this far, the guest-visible data WAS copied successfully.
'qemu-img compare' will report success. The only thing broken at this
point is a bogus bitmap, and leaving a just-created (but empty) bitmap
in place rather than erasing it (since we just created it a few lines
above) is not nice. I see no problem with keeping this cleanup path
intact, even if it is seldom reached, and even though we still exit
the overall qemu-img convert with an error.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
