From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRrlb-0000Qh-Ry for qemu-devel@nongnu.org; Wed, 20 Feb 2008 11:25:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRrlZ-0000Oz-Pk for qemu-devel@nongnu.org; Wed, 20 Feb 2008 11:25:55 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRrlZ-0000Oo-Jh for qemu-devel@nongnu.org; Wed, 20 Feb 2008 11:25:53 -0500 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRrlZ-0005hy-AV for qemu-devel@nongnu.org; Wed, 20 Feb 2008 11:25:53 -0500 Message-ID: <47BC5415.4020102@qumranet.com> Date: Wed, 20 Feb 2008 18:23:49 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] bdrv_flush error handling References: <18364.19722.241175.337829@mariner.uk.xensource.com> <20080220160457.GD14209@redhat.com> <200802201619.01354.paul@codesourcery.com> In-Reply-To: <200802201619.01354.paul@codesourcery.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 Paul Brook wrote: >>> Finally, it would perhaps be best if the block device emulators wrote >>> to the qemu console to complain if they give write errors. Otherwise >>> the errno value and other important information will be lost, which >>> makes debugging hard. >>> >> If by 'qemu console' you mean stderr, then fine, but please don't >> spew log messages to the monitor console, because that'll make it >> very hard to interact with reliably from management tools. >> > > Actually I think a better default would be for qemu to die right there and > then. If the host is getting IO errors then something is badly wrong, and > you're probably screwed anyway. > If you're passing through a real disk or volume, this denies the guest the possibility of recover y (for example, if it is running a RAID setup over multiple volumes, or if you are testing the guest's ability to recover from errors). For non-raw formats, you can pass through errors on data, but it is impossible to recover on metadata errors, so dying on I/O error should be fine. -- Any sufficiently difficult bug is indistinguishable from a feature.