From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LcPRz-0001mf-Os
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:29:47 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LcPRx-0001kU-VN
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:29:47 -0500
Received: from [199.232.76.173] (port=53448 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LcPRx-0001kG-Ix
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:29:45 -0500
Received: from qw-out-1920.google.com ([74.125.92.144]:4856)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LcPRx-0003Xp-7A
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:29:45 -0500
Received: by qw-out-1920.google.com with SMTP id 4so156511qwk.4
	for <qemu-devel@nongnu.org>; Wed, 25 Feb 2009 11:29:44 -0800 (PST)
Message-ID: <49A59C24.6010003@codemonkey.ws>
Date: Wed, 25 Feb 2009 13:29:40 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [6388] Stop VM on ENOSPC error.
References: <E1LPiI5-0004LB-5o@cvs.savannah.gnu.org>	<49A577FD.60701@codemonkey.ws>
	<20090225170422.GD8810@redhat.com>	<20090225173429.GV24969@redhat.com>	<49A58E64.3020303@codemonkey.ws>
	<20090225184839.GC16453@shareable.org>
In-Reply-To: <20090225184839.GC16453@shareable.org>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
>>> The idea is that if the guest at least sees the I/O error, then it won't
>>> continue writing as if everything were OK. It may not be able to continue
>>> normal operation, but it can at least mark the FS read-only and avoid
>>> ongoing damage.
>>>       
>> This simply doesn't happen in practice.  The FS needs to write data to 
>> the disk in order to remount it read-only.  Once all writes start 
>> failing, the errors are cascading.
>>     
>
> ext2/3/4 have documented errors=remount-ro / errors=panic mount options.
>
> Don't they work?
>   

This was a sles10sp1 guest which uses reiserfs by default.

Regards,

Anthony Liguori