qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] More qcow2 bugs? - qemu-img convert/commit
Date: Thu, 10 Sep 2009 00:26:54 +0100	[thread overview]
Message-ID: <20090909232654.GA20719@shareable.org> (raw)

Today I decided to take a gamble and run "qemu-img commit" on a couple
of qcow2 files that have backing files, because the qcow2s had become
as large as their backing file anyway.

The first one I did without thinking, confident that qcow2 bugs have
been squashed.  Foolish me, I put my faith in the tool and didn't keep
a backup of the VM disk images.  (They are quite large after all).

Then I got nervous, and for the second one I did this:

    qemu-img convert -O raw my_qcow2_branch flattened
    qemu-img commit my_qcow2_branch

    md5sum my_qcow2_backing_file flattened

The two md5sums _should_ be identical, shouldn't they?

In mine, the files have the same size but different md5sums.

The tool I used is qemu-img from kvm-88, which is the most recent
release on kvm's home page.

I ran script to find which sectors differed, and found a large number.
I stopped counting after the first million sectors, which is a lot,
considering the raw image is only 11GB.  Extrapolating, about 37% of
all the sectors did not match.

In all cases, the output of "convert" had all-zeros in those sectors
while the backing file after "commit" had non-zero data.

To which I think *phew*.  At least that gives me some confidence that
I didn't trash the file I ran "commit" on, and thank goodness I didn't
decide to use "convert" instead.  I had in the back of my mind that
"convert" might be safer because it would use more tested code paths
than "commit" - after all it could just use the same code as qemu and
qemu-nbd, whereas "commit" is more special.

37% is large enough to be a clue: Does it simply expand the qcow2 file
without reading the backing file at all?  A quick strace shows that
indeed, it does *open* the backing file and it does read the backing
file's header, but after that it doesn't read it at all.

Did I miss something obvious which means this is ok?

Should the output of "qemu-img convert" be identical to the backing
file after "qemu-img commit", assuming they are the same format?

Thanks,
-- Jamie

             reply	other threads:[~2009-09-09 23:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-09 23:26 Jamie Lokier [this message]
2009-09-09 23:42 ` [Qemu-devel] Re: More qcow2 bugs? - qemu-img convert/commit Paolo Bonzini
2009-09-10  8:27 ` [Qemu-devel] " Kevin Wolf
2009-09-10  8:32   ` Kevin Wolf
2009-09-10  9:44     ` Jamie Lokier
2009-09-10  9:46       ` Kevin Wolf
2009-09-10 12:27         ` Jamie Lokier
2009-09-11 19:28           ` Jamie Lokier

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=20090909232654.GA20719@shareable.org \
    --to=jamie@shareable.org \
    --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).