From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnnVD-0008MD-QG for qemu-devel@nongnu.org; Fri, 23 May 2014 07:19:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WnnV4-0007Bu-Rj for qemu-devel@nongnu.org; Fri, 23 May 2014 07:19:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WnnV4-0007BS-KT for qemu-devel@nongnu.org; Fri, 23 May 2014 07:18:58 -0400 Date: Fri, 23 May 2014 13:18:50 +0200 From: Kevin Wolf Message-ID: <20140523111850.GA5254@noname.redhat.com> References: <1400751770-14594-1-git-send-email-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1400751770-14594-1-git-send-email-stefanha@redhat.com> Subject: Re: [Qemu-devel] [PATCH] docs: clarify that qcow2 file size is not always a cluster multiple List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Maria Kustova , qemu-devel@nongnu.org, =?iso-8859-1?Q?Beno=EEt?= Canet Am 22.05.2014 um 11:42 hat Stefan Hajnoczi geschrieben: > Normally one would expect that qcow2 image file lengths are multiples of > the cluster size. This is not true in all cases and the spec should > document this so implementers remember to accept such files. > > $ qemu-img create -f qcow2 foo.qcow2 2G > Formatting 'foo.qcow2', fmt=qcow2 size=2147483648 encryption=off cluster_size=65536 lazy_refcounts=off > $ ls -l foo.qcow2 > -rw-r--r-- 1 stefanha stefanha 197120 May 22 11:40 foo.qcow2 > $ bc -q > 3 * (64 * 1024) + 512 > 197120 > > The extra sector are the 4 L1 table entries that a 2 GB disk with 64 KB > cluster size needs. The rest of the L1 table is omitted from the file > but allocation will continue at the next cluster boundary. > > Reported-by: Maria Kustova > Signed-off-by: Stefan Hajnoczi > --- > docs/specs/qcow2.txt | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt > index f19536a..a46ee57 100644 > --- a/docs/specs/qcow2.txt > +++ b/docs/specs/qcow2.txt > @@ -4,6 +4,10 @@ A qcow2 image file is organized in units of constant size, which are called > (host) clusters. A cluster is the unit in which all allocations are done, > both for actual guest data and for image metadata. > > +If the end of the image file is not on a cluster boundary, the missing data is > +treated as zeroes. This layout can occur when an L1 table or refcount table is > +the last thing in the file and not all entries in the table are used. > + > Likewise, the virtual disk as seen by the guest is divided into (guest) > clusters of the same size. Why don't we specify this for _any_ data after EOF, as we discussed on IRC, instead of just for a partial last cluster? If we restrict it to the last cluster, specifying the data as zero doesn't make a whole lot of sense because then the data there wouldn't be supposed to be interpreted anyway. Kevin