From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwK4B-0003n0-EQ for qemu-devel@nongnu.org; Wed, 03 Dec 2014 19:14:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwK44-0007TO-Rr for qemu-devel@nongnu.org; Wed, 03 Dec 2014 19:14:43 -0500 Received: from resqmta-ch2-10v.sys.comcast.net ([2001:558:fe21:29:69:252:207:42]:49576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwK44-0007TC-Nc for qemu-devel@nongnu.org; Wed, 03 Dec 2014 19:14:36 -0500 Message-ID: <547FA4E9.40302@redhat.com> Date: Wed, 03 Dec 2014 16:03:53 -0800 From: Eric Blake MIME-Version: 1.0 References: <1417613866-25890-1-git-send-email-mreitz@redhat.com> <1417613866-25890-27-git-send-email-mreitz@redhat.com> In-Reply-To: <1417613866-25890-27-git-send-email-mreitz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kvNHSersxDNEHbI2OFiuwbecvLrL0nPCD" 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: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kvNHSersxDNEHbI2OFiuwbecvLrL0nPCD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/03/2014 05:37 AM, Max Reitz wrote: > Add a test for conversion between different refcount widths and errors > specific to certain widths (i.e. snapshots with refcount_bits=3D1). >=20 > Signed-off-by: Max Reitz > --- > tests/qemu-iotests/112 | 296 +++++++++++++++++++++++++++++++++++++= ++++++++ > tests/qemu-iotests/112.out | 155 ++++++++++++++++++++++++ > tests/qemu-iotests/group | 1 + > 3 files changed, 452 insertions(+) > create mode 100755 tests/qemu-iotests/112 > create mode 100644 tests/qemu-iotests/112.out > +# This test will set refcount_bits on its own which would conflict wit= h the > +# manual setting; compat will be overridden as well > +_unsupported_imgopts refcount_bits 'compat=3D0.10' Should this be 'compat' rather than 'compat=3D0.10' as the filter? The reason I ask is that if I can pass an explicit 'compat=3D1.1'... > +echo > +echo '=3D=3D=3D refcount_bits and compat=3D0.10 =3D=3D=3D' > +echo > + > +# Should work > +IMGOPTS=3D"$IMGOPTS,compat=3D0.10,refcount_bits=3D16" _make_test_img 6= 4M =2E..is it going to conflict with this explicit compat=3D0.10? I didn't actually try this setup, though, so if the test passes with an explicit imgopt request for compat=3D1.1, then I'm fine with it as-is. Reviewed-by: Eric Blake 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. But I'm fine with doing that as a later patch, so don't hold up this series for it (unless you want to add a 27/26). See my mail here where I calculate the minimum size required to guarantee that situation at just under 256 megabytes with 512 byte clusters: https://lists.gnu.org/archive/html/qemu-devel/2014-11/msg03455.html But now that I looked that up, I just realized that that email did not calculate what it would take to get an L1 table to likewise occupy enough contiguous clusters to guarantee a refblock where every entry is pointing to clusters of the L1 table and therefore cannot be self-referential. But as both L1 and L2 table entries are 64 bits, it looks like the math is the same as for 64-bit width refcounts, so it happens to be the same magic size of just under 256 megabytes - and in this case, the magic value is hit even without relying on this series' addition of 64-bit refcount widths. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --kvNHSersxDNEHbI2OFiuwbecvLrL0nPCD 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 iQEcBAEBCAAGBQJUf6TpAAoJEKeha0olJ0Nq5isH/3qQ2rtC+iaNkqFl286g9zMz FoYavzFXuqHQ3dKyGX1TtuHecNbHbBAgE1LenCnYgOn8vPIdgS72HZqL1xcoK36H BMLRSana0BqWnNJj99s6nqm5R8kYQ+kE/d1cFUIM/wfH6hXLsaGaJgYYWbIxVLmD yjfvh/4poGW4jGw5JNvB8hd1bWlxwf4V7FLy50oy3jDMCXDrSIH51LOnv+hQ+CFh 5aGzoQ+QClIYdxA42JVObszxC2OvKFSf5NH6CjEelzCqjIP2vhlCMfoXoOrjnFCQ t5993fMkN/gyB75O0El7JAkI05jUuhwjoTmYzt0K5/nSpSU9i5gD/3ocQCXqdlc= =qhoR -----END PGP SIGNATURE----- --kvNHSersxDNEHbI2OFiuwbecvLrL0nPCD--