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
signature.asc
Description: OpenPGP digital signature
