From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaQDO-0004ig-PC for qemu-devel@nongnu.org; Mon, 29 Feb 2016 10:58:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaQDN-00049n-M6 for qemu-devel@nongnu.org; Mon, 29 Feb 2016 10:58:30 -0500 References: <20160227050038.X5XK3.255642.root@dnvrco-web06> <20160229140124.GC5004@noname.redhat.com> From: Eric Blake Message-ID: <56D46AA1.3040809@redhat.com> Date: Mon, 29 Feb 2016 08:58:25 -0700 MIME-Version: 1.0 In-Reply-To: <20160229140124.GC5004@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QKK05bPUmEKpX9hchgJqXLLpEiKL6uQb4" Subject: Re: [Qemu-devel] QCow2 compression List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , mgreger@cinci.rr.com Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QKK05bPUmEKpX9hchgJqXLLpEiKL6uQb4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/29/2016 07:01 AM, Kevin Wolf wrote: >> I have for example a compressed cluster with an L2 entry value of 4A >> C0 00 00 00 3D 97 50. This would lead me to believe the cluster starts= >> at offset 0x3D9750 and has a length of 0x2B 512-byte sectors (or 0x2B >> times 0x200 =3D 0x5600). Added to the offset this would give an end fo= r >> the cluster at offset 0x3DED50. However, it is clear from looking at >> the image that the compressed cluster extends further, the data ending= >> at 0x3DEDD5 and being followed by some zero padding until 0x3DEDF0 >> where the file ends. How can I know the data extends beyond the length= >> I calculated? Did I misunderstand the documentation somewhere? Why >> does the file end here versus a cluster aligned offset? >=20 > This zero padding happens in the very last cluster in the image in orde= r > to ensure that the image file is aligned to a multiple of the cluster > size (qcow2 images are defined to consist of "units of constant size", > i.e. only full clusters). The qcow2 spec is just fine with a host file that is not a multiple of a cluster size (the bytes not present must behave as if they read as 0). Whether we write explicit padding bytes or just truncate the file, on the last cluster, shouldn't matter. Although if we are only padding part of the way, that's a bit odd. > qemu-devel is alright for this kind of questions. I'm also copying > qemu-block now, which makes the email thread more visible for the > relevant people (as qemu-devel is relatively high traffic these days), > but qemu-devel should always be included anyway. Good idea, and sorry I wrote my first reply before seeing your message, where I didn't include qemu-block. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --QKK05bPUmEKpX9hchgJqXLLpEiKL6uQb4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJW1GqhAAoJEKeha0olJ0Nqh9IH/j2ieaGqmEPZINRHH+gtwcwk izG7cUrgw6qvVadr3vACeoupnLKYV7gOmZOKT+aBuSKDGp/IUiEQWT1LdN6PKbry EnGCRTsDfptjYI7zOWXD/ojqln/boj3cAXHsbrcAOca1lT1sRr1c2+cSl0a1ba8+ ASpKxUKJdBodYID/pIfvwMCffh+TdL/YwbHLXRaoR6+b/oA5DD+CdgCI6DoHsTsC i01WNnbfMNrp79ov3AIlXqhfGXiIpfYJh3ghFTjG0CEH/QIoc7/DyofLVgJhBXq5 2RPfCrXflXO6Ffty3fORLL56tW3j1g0fa3/Ln8zxOYdkzbxwrel1pbGnKvsZ2m4= =zKRB -----END PGP SIGNATURE----- --QKK05bPUmEKpX9hchgJqXLLpEiKL6uQb4--