Am 03.04.2020 um 19:58 hat Eric Blake geschrieben:
The use of 'qemu-img amend' to change qcow2 backing files is
not
tested very well. In particular, our implementation has a bug where
if a new backing file is provided without a format, then the prior
format is blindly reused, even if this results in data corruption, but
this is not caught by iotests.
There are also situations where amending other options needs access to
the original backing file (for example, on a downgrade to a v2 image,
knowing whether a v3 zero cluster must be allocated or may be left
unallocated depends on knowing whether the backing file already reads
as zero), but the command line does not have a nice way to tell us
both the backing file to use for opening the image as well as the
backing file to install after the operation is complete.
Even if we do allow changing the backing file, it is redundant with
the existing ability to change backing files via 'qemu-img rebase -u'.
It is time to deprecate this support (leaving the existing behavior
intact, even if it is buggy), and at a point in the future, require
the use of only 'qemu-img rebase' for adjusting backing chain
relations, saving 'qemu-img amend' for changes unrelated to the
backing chain.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
I think the original idea was that in BlockDriver, special interfaces
like the ones used by qemu-img rebase could eventually go away if we
have a single consistent interface to change image options, which is
amend. So ideally, bdrv_change_backing_file() should become a wrapper
around amend.
I'm not even sure if the behaviour you mention should be considered a
bug because amend is a low-level interface. But even if that's the case,
it would be a matter of simply adding a check.
Kevin