From: herbie hancock <hhancock@web.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible
Date: Sat, 17 Mar 2007 17:48:06 +0100 [thread overview]
Message-ID: <1736908044@web.de> (raw)
> -----Ursprüngliche Nachricht-----
> Von: qemu-devel@nongnu.org
> Gesendet: 16.03.07 13:11:15
> An: qemu-devel@nongnu.org
> Betreff: Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible
> herbie hancock wrote:
> > Hello, i had also a reproducible disk crash:
> > info of the last good image, size is about 3,5GB
> >
> > I never experienced such a bad problem with qemu before, maybe it is a problem with qcow2 format ?
>
> After the problems with qcow2 images which I reported here a few weeks
> ago, I've only been using qcow images (under QEMU 0.9.0), without such
> surprises. So it seems qemu has some bug related to qcow2 images,
> maybe manifesting itself only after they get larger than 4GB...
>
>
> Best regards
> J Esteves
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
I am quite sure now that it is a problem with the qcow2 format.
I can reprodue the bug only on a qcow2 image. I did a disk fill test with dd on a qcow2 Image and the same test on a qcow Image,
both images had the same content. (Image 16GB Debian 4.0 Etch, hda1 ext3 15 gb, hda5 swap 700MB)
The qcow2 Image was totally corrupted and is not bootable any more, the qcow Image passed the tests without any errors
Host system was now winxp sp2 instead of win2k, so i dont think its a problem of the host os.
I think a big warning for the users is necessary that they should work with qcow instead of qcow2 until the bug is fixed
Best regards
hr
Test Setup:
---------------
Made a copy of the last known good qcow2 image (size 3.3 GB) and converted it to qcow
..\QemuManager\qemu\qemu-img.exe convert debian4_0.dsk -O qcow debian4_0_qcow.dsk
Crashtest with debian4_0.dsk (qcow2 format)
-----------------------------------------------------------
Size of intact debian4_0.dsk 3.551.580.160 Bytes
file format: qcow2
virtual size: 16G (16777216000 bytes)
disk size: 3.3G
cluster_size: 4096
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 test 79M 2007-03-11 18:34:49 00:07:47.475
Start VM: I:\debian4.0\QemuManager\qemu\qemu.exe -L "I:\debian4.0\QemuManager\qemu" -m 256 -hda "I:\debian4.0\debian4\debian4_0.dsk" -cdrom "I:\debian4.0\debian4\debian-testing-i386-DVD-1.iso" -kernel-kqemu -net nic,vlan=0 -net user,vlan=0 -std-vga -localtime
fsck on mounted filesystem: fsck -nv /dev/hda1 show no errors except # of free inodes
df 19% of system used (Total: 15409468 used: 2641020)
fill the rest of the disk: dd if=/dev/zero of=/tmp/bigfile bs=16M
dd stops with disk full, ok
---> now fsck -nv /dev/hda1 shows endless output of errors <----- ERROR
rm bigfile
shutdown system did work
---> Restart VM: Fatal not a bootable harddisk ext3 is totally corrupt <------- ERROR
In this case there was no crash on the VM, as i had on WIN2K, header of the image file seems to be still intact
Info after crash:
image: debian4_0.dsk
file format: qcow2
virtual size: 16G (16777216000 bytes)
disk size: 16G <---- 16GB (why so much on a 15GB Partition ?)
cluster_size: 4096
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 test 79M 2007-03-11 18:34:49 00:07:47.475
Size of crashed debian4_0.dsk 16.659.554.304 Bytes
Test with debian4_0_qcow.dsk:
------------------------------------------
Size of debian4_0_qcow.dsk: 3.105.832.960 Bytes
image: debian4_0_qcow.dsk
file format: qcow
virtual size: 16G (16777216000 bytes)
disk size: 2.9G
cluster_size: 4096
Start VM: I:\debian4.0\QemuManager\qemu\qemu.exe -L "I:\debian4.0\QemuManager\qemu" -m 256 -hda "I:\debian4.0\debian4\debian4_0_qcow.dsk" -cdrom "I:\debian4.0\debian4\debian-testing-i386-DVD-1.iso" -kernel-kqemu -net nic,vlan=0 -net user,vlan=0 -std-vga -localtime
fsck on mounted filesystem: fsck -nv /dev/hda1 show no errors except # of free inodes
df 19% of system used (Total: 15409468 used: 2641020)
fill the rest of the disk: dd if=/dev/zero of=/tmp/bigfile bs=16M
dd stops with disk full, ok
now fsck -nv /dev/hda1 no errors
rm bigfile
shutdown system did work
image: debian4_0_qcow.dsk
file format: qcow
virtual size: 16G (16777216000 bytes)
disk size: 15G
cluster_size: 4096
Size of debian4_0_qcow.dsk: 15.919.493.120 Bytes
Start VM: all o.k.
-----------------------------------------------------
_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
next reply other threads:[~2007-03-17 16:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-17 16:48 herbie hancock [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-03-16 17:00 [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible Ben Taylor
2007-03-16 18:17 ` Julian Seward
2007-03-14 23:20 herbie hancock
2007-03-15 9:59 ` Julian Seward
2007-03-15 14:00 ` Thiemo Seufer
2007-03-16 12:01 ` J M Cerqueira Esteves
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=1736908044@web.de \
--to=hhancock@web.de \
--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).