WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Windows Bug Check 0x101 issue

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Windows Bug Check 0x101 issue
From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 26 Mar 2008 12:34:47 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Kouya Shimura <kouya@xxxxxxxxxxxxxx>, Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Delivery-date: Wed, 26 Mar 2008 05:51:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <18410.10932.522487.743717@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903
References: <7k4pawfnxs.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <C40D3B88.15566%keir.fraser@xxxxxxxxxxxxx> <7k1w5zf50j.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <18408.57824.846687.465435@xxxxxxxxxxxxxxxxxxxxxxxx> <20080325175718.GT4411@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7ky786dkup.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx> <18410.9596.488204.878357@xxxxxxxxxxxxxxxxxxxxxxxx> <20080326102744.3124cbb4@core> <18410.10932.522487.743717@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> Hrm.  I think it would be better to return an endless sequence of
> errors than to return no error at all.  Since we don't know which
> block failed, we could report an error flushing block 0, and then an
> error flushing block 1, and so on ?

On a raid volume that will give wrong results and incorrect recovery
behaviour. You need to report correct information. In addition a lot of
software treats repeated errors on flush as a device failure after a
certain count.

If a write to the underlying emulated media fails you know at least which
write fails and usually the page that failed (as you get a short write)

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel