From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LN9Zq-0001Tv-0O for qemu-devel@nongnu.org; Wed, 14 Jan 2009 12:30:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LN9Zo-0001Ry-2h for qemu-devel@nongnu.org; Wed, 14 Jan 2009 12:30:49 -0500 Received: from [199.232.76.173] (port=48342 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LN9Zn-0001Rj-TP for qemu-devel@nongnu.org; Wed, 14 Jan 2009 12:30:47 -0500 Received: from mx1.redhat.com ([66.187.233.31]:59339) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LN9Zn-00042m-G0 for qemu-devel@nongnu.org; Wed, 14 Jan 2009 12:30:47 -0500 Date: Wed, 14 Jan 2009 17:30:45 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] Stop VM on ENOSPC error Message-ID: <20090114173044.GS24995@redhat.com> References: <20090114120358.GS3267@redhat.com> <20090114121147.GI24995@redhat.com> <20090114164617.GB6431@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090114164617.GB6431@shareable.org> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org On Wed, Jan 14, 2009 at 04:46:17PM +0000, Jamie Lokier wrote: > Daniel P. Berrange wrote: > > Thus I'd suggest we need an async notification of this event, > > and only enable this behaviour if the app controlling QEMU has > > explicitly enabled this notification / feature. > > I think the behaviour should always be enabled (unless explicitly > disabled, but I'm not sure why you'd want to do that). > > A corrupt VM with data loss sounds much worse than a stopped VM to me. You're not corrupting data in current code - you're just unable to finish new writes, because an IO failure is propagated back to the guest. If the guest is properly checking for & handling I/O failures, it should be pretty much OK once the host space problem is resolved - perhaps a reboot + journal recovery. Older QEMU certainly had catastrophic data loss on ENOSPC due to not sending any I/O errors back to the guest, so it thought its write had succeeded when in fact it had been thrown away. Current QEMU is more careful about error propagation now. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|