qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] More qcow2 bugs? - qemu-img convert/commit
@ 2009-09-09 23:26 Jamie Lokier
  2009-09-09 23:42 ` [Qemu-devel] " Paolo Bonzini
  2009-09-10  8:27 ` [Qemu-devel] " Kevin Wolf
  0 siblings, 2 replies; 8+ messages in thread
From: Jamie Lokier @ 2009-09-09 23:26 UTC (permalink / raw)
  To: qemu-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2009-09-11 19:28 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-09 23:26 [Qemu-devel] More qcow2 bugs? - qemu-img convert/commit Jamie Lokier
2009-09-09 23:42 ` [Qemu-devel] " 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

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