qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v4 26/26] iotests: Add test for different refcount widths
Date: Thu, 04 Dec 2014 12:10:00 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

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).  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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]