From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZWzs-00085m-IY for qemu-devel@nongnu.org; Sat, 27 Feb 2016 00:00:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZWzp-0006qz-BJ for qemu-devel@nongnu.org; Sat, 27 Feb 2016 00:00:52 -0500 Received: from dnvrco-outbound-snat.email.rr.com ([107.14.73.227]:42722 helo=dnvrco-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZWzp-0006qF-6n for qemu-devel@nongnu.org; Sat, 27 Feb 2016 00:00:49 -0500 Message-ID: <20160227050038.X5XK3.255642.root@dnvrco-web06> Date: Sat, 27 Feb 2016 5:00:37 +0000 From: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] QCow2 compression List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hello, I am hoping someone here can help me. I am implementing QCow2 suppor= t for a PC emulator project and have a couple questions regarding compressi= on I haven't been able to figure out on my own. First some background: I am using the information I found at https://people.gnome.org/~markmc/qcow= -image-format.html and I have implemented working support for QCow2 images = as described there except for snapshots, encryption, and compression. Of th= ese, only compression is of immediate use to me. I have some QCow2 images all using 16-bit clusters created using qemu-img 2= .1.2 (the version bundled with Debian stable). According to the documentati= on I linked, 8 bits of an L2 table entry following the copy flag should say= how many 512 byte sectors a compressed cluster takes up and the remaining = bits are the actual offset of the cluster within the file. I have for examp= le 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 for the cluster at offset 0x3DED50. Ho= wever, it is clear from looking at the image that the compressed cluster ex= tends 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 some= where? Why does the file end here versus a cluster aligned offset? A final question: I noticed that compressed clusters typically have a refer= ence count higher than one, yet there are no snapshots present in the image= . I suspect the count is incremented for each compressed cluster that exist= s even partially within a normal sized cluster region of the file, but I ca= n find no documentation to this effect and am merely speculating. Am I corr= ect? If it is the wrong place to ask these questions, I would appreciate it if a= nyone could direct me to a more appropriate venue. Thank you for taking the= time to read this and tanks in advance for any assistance.