From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSarE-0004yP-H0 for qemu-devel@nongnu.org; Mon, 11 Aug 2008 13:07:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSarC-0004wy-JY for qemu-devel@nongnu.org; Mon, 11 Aug 2008 13:06:59 -0400 Received: from [199.232.76.173] (port=34138 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSarC-0004wi-9v for qemu-devel@nongnu.org; Mon, 11 Aug 2008 13:06:58 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]:10813) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSarA-0000CK-6o for qemu-devel@nongnu.org; Mon, 11 Aug 2008 13:06:56 -0400 Received: by nf-out-0910.google.com with SMTP id b2so649215nfb.12 for ; Mon, 11 Aug 2008 10:06:51 -0700 (PDT) Message-ID: <48A0714C.1040801@codemonkey.ws> Date: Mon, 11 Aug 2008 12:05:16 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] report read/write errors to IDE guest driver as ECC errors References: <20080805115506.GR4478@implementation.uk.xensource.com> <48990BC6.1050503@codemonkey.ws> <20080806092822.GC9055@redhat.com> <18592.27928.201904.615457@mariner.uk.xensource.com> In-Reply-To: <18592.27928.201904.615457@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Ian Jackson wrote: > Daniel P. Berrange writes ("Re: [Qemu-devel] [PATCH] report read/write errors to IDE guest driver as ECC errors"): > >> 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. >> > > Absolutely. > > >> Special ENOSPC handling can be added on top. >> I agree that pausing the guest is probably best option in that scenario, >> > > I disagree. Most reasonable guests will have special handling for > write failures on their disks. For example, Linux will (in the > default setup) remount the fs readonly precisely to prevent > corruption. > But corruption isn't the issue. The issue is that you're out of disk space. If using qcow, an attempt to remount the fs may result in even more errors if the qcow file has to expand (due to CoW). Consider the case of guest RAID. Once the ECC errors are detected, the guest will start trying to rebuild the failed drive and since we're already out of space, this is going to be catastrophic. This is why ENOSPC should be handled differently than EIO. > Pausing the guest denies the guest the ability to take whatever action > it really wants to. > I agree for EIO, but a guest cannot take any actions when ENOSPC occurs because it has no concept that such a thing can occur. Regards, Anthony Liguori > Ian. > > >