From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abhHm-0003cF-7y for qemu-devel@nongnu.org; Thu, 03 Mar 2016 23:24:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abhHj-0000Dl-0x for qemu-devel@nongnu.org; Thu, 03 Mar 2016 23:24:18 -0500 Received: from dnvrco-outbound-snat.email.rr.com ([107.14.73.232]:64883 helo=dnvrco-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abhHi-0000DY-S9 for qemu-devel@nongnu.org; Thu, 03 Mar 2016 23:24:14 -0500 Message-ID: <20160304042411.UUWFM.307100.root@dnvrco-web23> Date: Fri, 4 Mar 2016 4:24:11 +0000 From: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QCow2 compression List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > 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 = 0x5600). Added to the offset this would give an end for > > 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? > > This zero padding happens in the very last cluster in the image in order > 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 zeros are not part of the compressed data, though, that's why the > Compressed Cluster Descriptor indicates a shorter size. Had another > compressed cluster been written to the same image, it might have ended > up where you are seeing the zero padding now. (The trick with > compression is that multiple guest clusters can end up in a single host > cluster.) > Thanks, but the given length of 0x5600 is still short by 160(decimal) bytes compared to the non-zero data (which occupies an additional 133 bytes beyond the expected end at 0x3DED50) and zero padding (an additional 27 bytes beyond that). Could there be an off-by-one error somewhere? The file doesn't even end on a sector boundary let alone a cluster boundary. I can replicate this easily and produce files which demonstrate what I am seeing here. I will try to replicate using a newer version of the qemu-img. The version in Debian stable is quite old apparently.