From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ubtug-00021v-Jd for qemu-devel@nongnu.org; Mon, 13 May 2013 10:39:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ubtuf-00028h-88 for qemu-devel@nongnu.org; Mon, 13 May 2013 10:39:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ubtuf-00028a-04 for qemu-devel@nongnu.org; Mon, 13 May 2013 10:39:41 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4DEddka022740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 May 2013 10:39:39 -0400 Date: Mon, 13 May 2013 15:39:35 +0100 From: "Richard W.M. Jones" Message-ID: <20130513143935.GH4515@redhat.com> References: <1368452576-32262-1-git-send-email-kwolf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1368452576-32262-1-git-send-email-kwolf@redhat.com> Subject: Re: [Qemu-devel] [PATCH for-1.5 0/3] qcow2: Catch some L1 table index overflows List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, stefanha@redhat.com On Mon, May 13, 2013 at 03:42:53PM +0200, Kevin Wolf wrote: [...] I tested the first patch (didn't try the tests) with qemu-img and libguestfs and it works. New qemu-img fails with: qemu-img: The image size is too large for file format 'qcow2' If you use the old qemu-img to create the file, and then try to add it with the new qemu, you get: -drive file=/tmp/huge.qcow2,cache=none,id=hd0,if=none: could not open disk image /tmp/huge.qcow2: File too large (instead of a segfault). So: ACK. Tested-by: Richard W.M. Jones My only gripe is it would be nice if the qemu-img error message mentioned that you can use the -o cluster_size=XXX option. > Suggestions for a better test case are welcome. But now that creating a large > image file fails, and if you somehow manage to create it anyway (qcow2.py) > opening it fails, it's hard to test the actual read/write cases. It'd be nice if the test included a test of the huge case using -o cluster_size=2M and a few reads and writes at the end of the disk, just to make sure this doesn't break in future. Also nice to have would be to be able to specify disk sizes using 'P' and 'E' :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/