From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LYfSg-00010s-Gp for qemu-devel@nongnu.org; Sun, 15 Feb 2009 06:47:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LYfSe-00010d-Bg for qemu-devel@nongnu.org; Sun, 15 Feb 2009 06:47:01 -0500 Received: from [199.232.76.173] (port=58592 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYfSe-00010a-7U for qemu-devel@nongnu.org; Sun, 15 Feb 2009 06:47:00 -0500 Received: from mail-fx0-f20.google.com ([209.85.220.20]:53189) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LYfSd-0003b5-R9 for qemu-devel@nongnu.org; Sun, 15 Feb 2009 06:47:00 -0500 Received: by fxm13 with SMTP id 13so5057875fxm.10 for ; Sun, 15 Feb 2009 03:46:58 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20090215105718.GH25994@redhat.com> References: <20090211070049.GA27821@shareable.org> <49955681.9070301@suse.de> <20090215105718.GH25994@redhat.com> Date: Sun, 15 Feb 2009 03:46:58 -0800 Message-ID: From: Marc Bevand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: qcow2 corruption observed, fixed by reverting old change Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Kevin Wolf , kvm@vger.kernel.org, qemu-devel@nongnu.org On Sun, Feb 15, 2009 at 2:57 AM, Gleb Natapov wrote: > > I am not able to reproduce this. After more then hundred boot linux; generate > disk io; quit loops all I've got is an image with 7 leaked blocks and > couple of filesystem corruptions that were fixed by fsck. The type of activity occuring in the guest is most likely an important factor determining the probability of the bug occuring. So you should try running guest OSes I remember having been affected by it: Windows 2003 SP2 x64. And now that I think about it, I don't recall any other guest OS having been a victim of that bug... coincidence ? Other factors you might consider when trying to reproduce: the qcow2 images that ended up being corrupted had a backing file (a read-only qcow2 image); NPT was in use; the host filesystem was xfs; my command line was: $ qemu-system-x86_64 -name xxx -monitor stdio -vnc xxx:xxx -hda hda -net nic,macaddr=xx:xx:xx:xx:xx:xx,model=rtl8139 -net tap -boot c -cdrom "" -cpu qemu64 -m 1024 -usbdevice tablet -marc