From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwT47-0007qh-9d for qemu-devel@nongnu.org; Thu, 04 Dec 2014 04:51:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwT42-0006V3-E6 for qemu-devel@nongnu.org; Thu, 04 Dec 2014 04:51:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwT42-0006Ul-6H for qemu-devel@nongnu.org; Thu, 04 Dec 2014 04:51:10 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB49p7Vx032095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 4 Dec 2014 04:51:08 -0500 Message-ID: <54802E89.8030500@redhat.com> Date: Thu, 04 Dec 2014 10:51:05 +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> In-Reply-To: <547FA4E9.40302@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 01:03, Eric Blake wrote: > 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=1). >> >> 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 with the >> +# manual setting; compat will be overridden as well >> +_unsupported_imgopts refcount_bits 'compat=0.10' > Should this be 'compat' rather than 'compat=0.10' as the filter? The > reason I ask is that if I can pass an explicit 'compat=1.1'... > >> +echo >> +echo '=== refcount_bits and compat=0.10 ===' >> +echo >> + >> +# Should work >> +IMGOPTS="$IMGOPTS,compat=0.10,refcount_bits=16" _make_test_img 64M > ...is it going to conflict with this explicit compat=0.10? > > I didn't actually try this setup, though, so if the test passes with an > explicit imgopt request for compat=1.1, then I'm fine with it as-is. Yes, it works; the last option given counts (see iotest 082). > Reviewed-by: Eric Blake Thank you! > 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. Max > 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. >