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@xxxxxxxxxx> 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
