Re: [Qemu-devel] [PATCH v4 26/26] iotests: Add test for different refcount widths

[Max Reitz <mreitz@redhat.com>]

On 2014-12-04 at 20:10, Eric Blake wrote:
> On 12/04/2014 02:51 AM, Max Reitz wrote:
>
>>> Side note:
>>>
>>> Now that we can produce MUCH smaller images where the reftable can
>>> easily require enough contiguous clusters to require the creation of at
>>> least one refblock that cannot be self-referential, it would probably be
>>> good to modify an existing test and/or add a new test to prove that we
>>> don't trip up when trying to create and read such an image.
>> Reading is rarely a problem because we don't even need to read the
>> refcounts then. However, creation may indeed be (or better: it should
>> not be), so I will see to add a test later on.
> Such a test is not necessarily quick.  On my machine with a spinning
> rust disk,
>
> qemu-img create -f qcow2 -ocluster_size=512 image 256M
> qemu-io -c 'write -P 0x22 0 256M' image
>
> took several minutes (I'm not sure if that is all because of 512-byte
> operations needing read-modify-write operations on the underlying
> filesystem, or I ended up with a safer-but-slower cache mode that was
> flushing a lot more often than necessary).

Maybe preallocation=metadata is enough. Also, preallocation=metadata 
makes later write operations much faster.

But actually I didn't even plan to write all the data. The L1 table 
should cover the whole image even without any data being there; and for 
adjusting the reftable size, it should be enough to write some data at 
some large offset.

Max

> And running 'qemu-img map
> image' in another terminal during that time to watch progress sometimes
> dumped core due to assertion failures about unexpected nb_clusters (but
> that's to be expected - reading an image in one process while another is
> actively modifying it is prone to cause grief to the reader).
>
> But the resulting image was successfully completed, and appears to be
> valid.  Although I didn't find an easy way to determine where the L1
> table actually ended up, and whether it really did cause the creation of
> at least one refblock that was not self-referential.
>