From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xwomc-0001Uh-6F for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:02:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwomV-0003xK-VJ for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:02:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwomM-0003sk-SY for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:02:31 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB592JNv009855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 5 Dec 2014 04:02:20 -0500 Message-ID: <54817497.4010808@redhat.com> Date: Fri, 05 Dec 2014 10:02:15 +0100 From: Max Reitz MIME-Version: 1.0 References: <1417613866-25890-1-git-send-email-mreitz@redhat.com> <1417613866-25890-27-git-send-email-mreitz@redhat.com> <547FA4E9.40302@redhat.com> <54802E89.8030500@redhat.com> <5480B188.9050304@redhat.com> In-Reply-To: <5480B188.9050304@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 26/26] iotests: Add test for different refcount widths List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi 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. >