On 3/10/21 9:59 AM, Max Reitz wrote:
> One clear problem with how qcow2's refcount structure rebuild algorithm
> used to be before "qcow2: Improve refcount structure rebuilding" was
> that it is prone to failure for qcow2 images on block devices: There is
> generally unused space after the actual image, and if that exceeds what
> one refblock covers, the old algorithm would invariably write the
> reftable past the block device's end, which cannot work. The new
> algorithm does not have this problem.
>
> Test it with three tests:
> (1) Create an image with more empty space at the end than what one
> refblock covers, see whether rebuilding the refcount structures
> results in a change in the image file length. (It should not.)
>
> (2) Leave precisely enough space somewhere at the beginning of the image
> for the new reftable (and the refblock for that place), see whether
> the new algorithm puts the reftable there. (It should.)
>
> (3) Test the original problem: Create (something like) a block device
> with a fixed size, then create a qcow2 image in there, write some
> data, and then have qemu-img check rebuild the refcount structures.
> Before HEAD^, the reftable would have been written past the image
> file end, i.e. outside of what the block device provides, which
> cannot work. HEAD^ should have fixed that.
> ("Something like a block device" means a loop device if we can use
> one ("sudo -n losetup" works), or a FUSE block export with
> growable=false otherwise.)
We could use qemu-nbd as another alternative to create a non-growable
protocol layer. Then we don't need root access via sudo to run the test.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
