From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xwwuc-0006R3-OI for qemu-devel@nongnu.org; Fri, 05 Dec 2014 12:43:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwwuX-0003V8-OP for qemu-devel@nongnu.org; Fri, 05 Dec 2014 12:43:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwwuX-0003V4-Hf for qemu-devel@nongnu.org; Fri, 05 Dec 2014 12:43:21 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB5HhKL9018554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 5 Dec 2014 12:43:20 -0500 Message-ID: <5481EEB7.9030308@redhat.com> Date: Fri, 05 Dec 2014 10:43:19 -0700 From: Eric Blake MIME-Version: 1.0 References: <1417798412-15330-1-git-send-email-mreitz@redhat.com> In-Reply-To: <1417798412-15330-1-git-send-email-mreitz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hDpQdfU7CS7iF8fWppsf5rFN1SbohGrGw" Subject: Re: [Qemu-devel] [PATCH] iotests: Test non-self-referential qcow2 refblocks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hDpQdfU7CS7iF8fWppsf5rFN1SbohGrGw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/05/2014 09:53 AM, Max Reitz wrote: > It is easy to create only self-referential refblocks, but there are > cases where that is impossible. This adds a test for two of those cases= > (combined in a single test case). >=20 > Suggested-by: Eric Blake > Signed-off-by: Max Reitz > --- > This patch depends on version 4 (or hopefully any later version) of my > "qcow2: Support refcount orders !=3D 4" series. > --- > tests/qemu-iotests/115 | 95 ++++++++++++++++++++++++++++++++++++++= ++++++++ > tests/qemu-iotests/115.out | 8 ++++ > tests/qemu-iotests/group | 1 + > 3 files changed, 104 insertions(+) > create mode 100755 tests/qemu-iotests/115 > create mode 100644 tests/qemu-iotests/115.out > + > +# One refblock can describe (with cluster_size=3D512 and refcount_bits= =3D64) > +# 512/8 =3D 64 clusters, therefore the L1 table should cover 128 clust= ers, which > +# equals 128 * (512/8) =3D 8192 entries (actually, 8192 - 512/8 =3D 81= 29 would This math is slightly off; you really only need 127 consecutive clusters to guarantee that you have an aligned 64 clusters somewhere in the mix. Also, 8192 - 512/8 =3D 8128 (you are missing the +1 L2 entry that is necessary to ensure the rollover to 128 clusters). The real minimum of L2 entries to provoke the situation we are after is thus 127 * (512/8) - 512/8 + 1 =3D 8065... > +# suffice, but it does not really matter). 8192 L2 tables can in turn = describe =2E..at any rate, your conclusion that it does not really matter is correct; and rounding up to the actual power of 2 is both easier to explain and more likely to happen in practice (I'm not going to go out of my way to create a 255.9M guest image, after all). So, whether or not you want to tweak the comment wording, the test itself is correct. Reviewed-by: Eric Blake > +# 8192 * 512/8 =3D 524,288 clusters which cover a space of 256 MB. > + > +# Since with refcount_bits=3D64 every refcount block entry is 64 bits = wide (just > +# like the L2 table entries), the same calculation applies to the refc= ount table > +# as well; the difference is that while for the L1 table the guest dis= k size is > +# concerned, for the refcount table it is the image length that has to= be at > +# least 256 MB. We can achieve that by using preallocation=3Dmetadata = for an image > +# which has a guest disk size of 256 MB. > + > +IMGOPTS=3D"$IMGOPTS,refcount_bits=3D64,cluster_size=3D512,preallocatio= n=3Dmetadata" \ > + _make_test_img 256M Wow - that's MUCH faster than my earlier message that omitted preallocation then used qemu-io as a followup (around 8 seconds on my machine); but ALSO much more fragmented (the resulting image, per qemu-img map, of my multi-minute approach had guest data runs of mainly 0x8000 bytes at a time, with a few 0x7e00 and 0x8200 sprinkled in, while your preallocation has lots of runs of 0x200 (1 cluster), 0x400 and so on, a few runs of 0x1000 or larger, but no run larger than 0x1a00). But I did confirm with 'qemu-img map -f raw' that the file is non-sparse, so you indeed covered both L1 and reftables. [and seeing how fragmented things can be makes me wonder what sort of performance gains we could get, if any, by writing a qcow2 defragmenter - but that's a project for another day, if ever] > +++ b/tests/qemu-iotests/group > @@ -115,3 +115,4 @@ > 111 rw auto quick > 112 rw auto > 114 rw auto quick > +115 rw auto 8 seconds is still pretty slow, so I agree with not marking this 'quick'.= --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --hDpQdfU7CS7iF8fWppsf5rFN1SbohGrGw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUge63AAoJEKeha0olJ0NqmdwH/RW5ci7V+Sj+yDnSTcxqYgCR JBS85cFOt209LEKzsjHf8IkKQwe7x2CgED3o8cmT9ATfZbCwJaEVhZFugaREX4DP QRE9dOLrkmi74y0bVSpwwnvfhRShlUbYF/YvflkSsGETmqVZBIpitOQ58xTeaSSq 54xgB9/s5mHfl3JaoCRsOrdtEHYuthGzroS9jAwW/YC/OXMjzne3RSxOhB0Woe3x l7wMN63eqaoZdT8l7SBf3eNZDe7WQML2Gs3GQpzi8vMOUcEL855ZBToW8TzKRs5l b53e5zD3tn1bD7l1W24N2lCEOELFB4oRZt4jIGmlR1qRRbZhKGCLUTeYBB+gUqE= =hVVT -----END PGP SIGNATURE----- --hDpQdfU7CS7iF8fWppsf5rFN1SbohGrGw--