qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] QCow2 compression


From: mgreger
Subject: [Qemu-devel] QCow2 compression
Date: Sat, 27 Feb 2016 5:00:37 +0000

Hello, I am hoping someone here can help me. I am implementing QCow2 support 
for a PC emulator project and have a couple questions regarding compression 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 these, 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 documentation 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 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?

A final question: I noticed that compressed clusters typically have a reference 
count higher than one, yet there are no snapshots present in the image. I 
suspect the count is incremented for each compressed cluster that exists even 
partially within a normal sized cluster region of the file, but I can find no 
documentation to this effect and am merely speculating. Am I correct?

If it is the wrong place to ask these questions, I would appreciate it if 
anyone could direct me to a more appropriate venue. Thank you for taking the 
time to read this and tanks in advance for any assistance.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]