From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRtSA-0002M1-6J for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:13:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRtS7-0002JB-VE for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:13:57 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRtS7-0002J2-JC for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:13:55 -0500 Received: from mail2.shareable.org ([80.68.89.115]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JRtS7-0006po-9D for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:13:55 -0500 Date: Wed, 20 Feb 2008 16:31:56 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] bdrv_flush error handling Message-ID: <20080220163155.GA5520@shareable.org> References: <18364.19722.241175.337829@mariner.uk.xensource.com> <47BC5415.4020102@qumranet.com> <18364.22321.98451.446676@mariner.uk.xensource.com> <200802201646.05521.paul@codesourcery.com> <18364.23313.189546.386460@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18364.23313.189546.386460@mariner.uk.xensource.com> 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 Cc: Paul Brook Ian Jackson wrote: > Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"): > > Disk full is a fundamentally unfriendly situation to be in. There is no good > > answer. Reporting errors back to the host has its own set of problems. Many > > guest OS effectively just lock up when this occurs. > > I think that's fine, surely ? A locked up guest isn't very nice but > it's better than a guest shot dead. Well, a guest which receives an IDE write error might do things like mark parts of the device bad, to avoiding writing to those parts. If the guest is running software RAID, for example, it will radically change its behaviour in response to those errors. Sometimes that's what you want, but sometimes it is really unwanted. If the host runs out of disk space, ideally you might want to suspend the guest until you can free up host disk space (or move to another host), then resume the guest, perhaps manually. Is savevm-upon-disk-full a realistic prospect? -- Jamie