From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQfJh-00054f-84 for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:28:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQfJg-000522-C8 for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:28:24 -0400 Received: from [199.232.76.173] (port=57312 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQfJf-00051s-Ty for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:28:23 -0400 Received: from mx1.redhat.com ([66.187.233.31]:55667) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQfJf-0002hn-HQ for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:28:23 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m769SNTk022086 for ; Wed, 6 Aug 2008 05:28:23 -0400 Received: from file.fab.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m769SM8I003313 for ; Wed, 6 Aug 2008 05:28:22 -0400 Received: (from berrange@localhost) by file.fab.redhat.com (8.13.1/8.13.1/Submit) id m769SMBo010221 for qemu-devel@nongnu.org; Wed, 6 Aug 2008 10:28:22 +0100 Date: Wed, 6 Aug 2008 10:28:22 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] report read/write errors to IDE guest driver as ECC errors Message-ID: <20080806092822.GC9055@redhat.com> References: <20080805115506.GR4478@implementation.uk.xensource.com> <48990BC6.1050503@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48990BC6.1050503@codemonkey.ws> 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: qemu-devel@nongnu.org On Tue, Aug 05, 2008 at 09:26:14PM -0500, Anthony Liguori wrote: > Samuel Thibault wrote: > >report read/write errors to IDE guest driver as ECC errors > >so that the guest knows that e.g. writes on read-only backends have > >failed. > > > >Signed-off-by: Samuel Thibault > > > > I'm glad you sent this patch as I think it's something we really need to > improve in QEMU. > > A patch like this has appeared on the list a number of times, and each > time it meets with a fair bit of criticism. The most cited issue is > that indiscriminately passing IO errors to the guest is not really > correct. If you're passing through a drive, then EIO errors are pretty > reasonable to pass through as an ECC error. If you're dealing with a > file, generating an ECC error on ENOSPC is not really accurate. The > guest cannot really do anything about that either and is likely to just > further corrupt itself. If you have a journalling filesystem, the worst that'll happen in the ENOSPC scenario is that you'll loose data from the open application files that aren't flusshed to disk - no different to pulling the power plug. The filesystem itself will not corrupt itself - it'll happily recover the journal & carry on after rebootint. > I think a patch like this is good in theory but it needs to do a better > job only handling the case where an error occurs that ECC really makes > sense. > > For things like ENOSPC, there are better error handling strategies. For > instance, vm_stop()'ing the guest and printing out an error message. > This would allow the admin to free up some space, and then resume the > guest. Even if you just stubbed these things out with FIXMEs, it would > be better than pretending that these cases didn't exist :-) Unless someone wants to implement the ENOSPC handling right now, I'd like to see this patch just committed as is, so we at least get incremental benefit over current behaviour, which definitely *does* corrupt guest filesystems by silently pretending the write succeeed. Special ENOSPC handling can be added on top. I agree that pausing the guest is probably best option in that scenario, the interesting question being how to inform management tools/API that the VM has just paused itself. In libvirt we handle pause/resume by doing 'stop'/'cont' in the QEMU monitor, and since we're triggering it ourselves we can track the state change from running to paused. If the VM pauses itself though we nee to figure out a way to detect this state change. The monitor doesn't have any asynchronous notification capability as it stands. 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 :|