All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.