From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WotXZ-0005NF-NH for qemu-devel@nongnu.org; Mon, 26 May 2014 07:58:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WotXT-00043j-Iw for qemu-devel@nongnu.org; Mon, 26 May 2014 07:58:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WotXT-00043N-Ap for qemu-devel@nongnu.org; Mon, 26 May 2014 07:57:59 -0400 Date: Mon, 26 May 2014 13:57:52 +0200 From: Stefan Hajnoczi Message-ID: <20140526115752.GC10187@stefanha-thinkpad.redhat.com> References: <1400751770-14594-1-git-send-email-stefanha@redhat.com> <20140523111850.GA5254@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140523111850.GA5254@noname.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: Kevin Wolf Cc: Maria Kustova , qemu-devel@nongnu.org, =?iso-8859-1?Q?Beno=EEt?= Canet On Fri, May 23, 2014 at 01:18:50PM +0200, Kevin Wolf wrote: > Am 22.05.2014 um 11:42 hat Stefan Hajnoczi geschrieben: > > 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. That's too general. Specifying it that way means almost all offsets become valid because you're just supposed to read zeroes! That will definitely cause trouble, let's be stricter here. Stefan