From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGlu7-0004er-Mr for qemu-devel@nongnu.org; Tue, 03 Sep 2013 04:24:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VGlu1-00076h-NL for qemu-devel@nongnu.org; Tue, 03 Sep 2013 04:24:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGlu1-000755-FN for qemu-devel@nongnu.org; Tue, 03 Sep 2013 04:23:57 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r838NuB9005077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Sep 2013 04:23:56 -0400 Date: Tue, 3 Sep 2013 10:23:59 +0200 From: Kevin Wolf Message-ID: <20130903082359.GC2683@dhcp-200-207.str.redhat.com> References: <1378116246-12855-1-git-send-email-mreitz@redhat.com> <1378116246-12855-6-git-send-email-mreitz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1378116246-12855-6-git-send-email-mreitz@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 5/5] qemu-iotest: qcow2 image option amendment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 02.09.2013 um 12:04 hat Max Reitz geschrieben: > Add tests for qemu-img amend on qcow2 image files. > > Signed-off-by: Max Reitz > --- > tests/qemu-iotests/061 | 178 +++++++++++++++++++++++ > tests/qemu-iotests/061.out | 349 +++++++++++++++++++++++++++++++++++++++++++++ > tests/qemu-iotests/group | 1 + > 3 files changed, 528 insertions(+) > create mode 100755 tests/qemu-iotests/061 > create mode 100644 tests/qemu-iotests/061.out It might be worth adding test cases for... * Leaving an encrypted image encrypted, implicitly or explicitly * Zero cluster expansion with an (active/inactive) L2 table with refcount > 1 * State after a failed amend operation (or do we even promise anything? I guess if you pass multiple options, some may be applied and some not) What's there looks good (except for the one bug I mentioned) Kevin