From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZELP-0006Uz-JQ for qemu-devel@nongnu.org; Mon, 16 Feb 2009 20:01:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZELP-0006Un-3q for qemu-devel@nongnu.org; Mon, 16 Feb 2009 20:01:51 -0500 Received: from [199.232.76.173] (port=60672 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZELP-0006Uk-1c for qemu-devel@nongnu.org; Mon, 16 Feb 2009 20:01:51 -0500 Received: from mail2.shareable.org ([80.68.89.115]:40900) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LZELO-0004MM-EV for qemu-devel@nongnu.org; Mon, 16 Feb 2009 20:01:50 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LZELJ-0005VE-TY for qemu-devel@nongnu.org; Tue, 17 Feb 2009 01:01:45 +0000 Date: Tue, 17 Feb 2009 01:01:45 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Revert block-qcow2.c to kvm-72 version due to corruption reports Message-ID: <20090217010145.GE20713@shareable.org> References: <4988AD96.6090308@codemonkey.ws> <20090213084023.GA1020@kos.to> <20090213163043.GJ18471@shareable.org> <4995A723.9010208@codemonkey.ws> <20090213190419.GB20328@shareable.org> <4997502D.1080401@codemonkey.ws> <20090215020126.GA9281@shareable.org> <20090215154207.GA24821@shareable.org> <49985CB7.4090803@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49985CB7.4090803@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > >>>>It's QEMU SVN delta 5005-5006, copied below. > >>>> > >>So why such an aggressive revert? Why not just revert the problematic > >>changesets? > > > >Because most of the following changes look too dependent on it. > > > > Too dependent on the introduced functionality or too dependent to make > porting trivial? My impression upon looking was that it's the later, My impression is the former, in that it seems necessary to understand the changes in 5006 to understand how to rewrite subsequent patches which use the changed functions. But I didn't spend a long time on it, as I can't. Of course all such things reduce to trivial porting if you have enough time. > But many of the changes since 5005 were also corruption fixes. And > let's be clear, your data is *not* safe with qcow2. So I don't consider > this to be a show stopping issue. There's a HUGE difference between "not safe if the host/QEMU crashes" and "corrupts silently during normal operation with no errors". The former is a rare event we hope. Marc's report, based apparently on a big farm of VMs, is that he observes this corruption a lot with Windows guests. The scary thing is it looks like it doesn't have anything (directly) to do with the device emulation, which is more sensitive to guest OS type. I wonder if people using kvm >= 73 have silent corruption in their Linux guests without noticing yet. -- Jamie