From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPCrA-0002GU-1G for qemu-devel@nongnu.org; Tue, 20 Jan 2009 04:25:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPCr7-0002Au-4o for qemu-devel@nongnu.org; Tue, 20 Jan 2009 04:25:11 -0500 Received: from [199.232.76.173] (port=56491 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPCr6-0002Ad-Vs for qemu-devel@nongnu.org; Tue, 20 Jan 2009 04:25:09 -0500 Received: from mx2.redhat.com ([66.187.237.31]:52735) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPCr6-0004SS-FU for qemu-devel@nongnu.org; Tue, 20 Jan 2009 04:25:08 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0K9P7IP029580 for ; Tue, 20 Jan 2009 04:25:07 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0K9P7wP009100 for ; Tue, 20 Jan 2009 04:25:07 -0500 Received: from zweiblum.travel.kraxel.org (vpn-10-45.str.redhat.com [10.32.10.45]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0K9P5Uo014024 for ; Tue, 20 Jan 2009 04:25:06 -0500 Message-ID: <49759870.3050305@redhat.com> Date: Tue, 20 Jan 2009 10:25:04 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v3] Stop VM on ENOSPC error. References: <20090118110509.GG11299@redhat.com> <18804.27240.886522.337700@mariner.uk.xensource.com> <4974A704.3070605@codemonkey.ws> <18804.46780.936806.748045@mariner.uk.xensource.com> In-Reply-To: <18804.46780.936806.748045@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 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: > Anthony Liguori writes ("Re: [Qemu-devel] [PATCH v3] Stop VM on ENOSPC error."): >> Ian Jackson wrote: >>> Once again, this feature should be optional. >> Why? > > Well, three reasons, one general and theoretical, and two practical > and rather Xen-specific. > > The theoretical reason is that a guest is in a better postion to deal > with the situation because it knows its access patterns. Often the > response to a failing write in a mission-critical system will be some > kind a fallback behaviour, which is likely to work. Stopping the VM > unconditionally is not something that the guest can cope with. The fundamental issue is that you can't signal ENOSPC to the guest via IDE protocol because that is an error condition which simply can't happen on real hardware. You can only signal EIO, which is something very different, and the OS likely goes into "Oops, disk broken" mode. Which probably isn't what you want here ... It might make sense to signal ENOSPC to the guest with a paravirtual disk. Then the guest knows what really happened has at least the chance to do something more reasonable in response, although I suspect most of the guests out there today wouldn't. > But in the Xen context, a Xen VM is not a `task' in the same way. > (Xen users make much less use of the built-in cow formats for this > reason, often preferring LVM snapshots or even deeper storage magic.) With LVM volumes as storage you shouldn't run into ENOSPC error conditions in the first place, and the patch should be a no-op for you. cheers, Gerd