I ran QEMU on Valgrind for several hours last night, including a couple of boot-shutdown cycles of RedHat8, and lots of file copying/deletion in the guest to get the qcow2 image up to 8GB and generally cause a lot of disk IO. I got no memory errors whatsoever from Valgrind and got no filesystem corruption, so I guess I didn't trigger the bug.
Really the first thing to do is establish a reliable way to reproduce it. J On Friday 16 March 2007 17:00, Ben Taylor wrote: > ---- J M Cerqueira Esteves <[EMAIL PROTECTED]> wrote: > > 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... > > I suspect I saw problems with qcow2 images as well. I was able to suspend > a Solaris Nevada B58 install and use savevm about 30% into the install and > restart it later. As the image completd, the file system went all to hell > with corruption that was impossible to fix. At the time, I attributed it > to the Solaris install (thinking it might have something to do with the > cmpxchg8b bug that was later fixed), but I suspect with the multiple > reports I've seen, I'm now thinking I saw the same thing. > > I'm testing conversion of a qcow image to a qcow2 image. We'll see how > that goes > > Ben > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
