Re: [Qemu-devel] QCow2 compression

[<mgreger@cinci.rr.com>]

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