From: <mgreger@cinci.rr.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] QCow2 compression
Date: Sat, 27 Feb 2016 5:00:37 +0000 [thread overview]
Message-ID: <20160227050038.X5XK3.255642.root@dnvrco-web06> (raw)
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.
next reply other threads:[~2016-02-27 5:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-27 5:00 mgreger [this message]
2016-02-29 14:01 ` [Qemu-devel] QCow2 compression Kevin Wolf
2016-02-29 15:58 ` Eric Blake
2016-02-29 14:59 ` Eric Blake
2016-02-29 15:54 ` Eric Blake
-- strict thread matches above, loose matches on Subject: below --
2016-03-04 4:24 mgreger
2016-03-04 22:19 ` Eric Blake
2016-03-05 0:11 mgreger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160227050038.X5XK3.255642.root@dnvrco-web06 \
--to=mgreger@cinci.rr.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).