Re: [Qemu-devel] QCow2 compression

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

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 = 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 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]