Date: Wed, 17 Jul 2002 15:46:37 +0200 (CEST)
From: Joerg Schilling <schilling@fokus.gmd.de>
Message-Id: <200207171346.g6HDkb1l028358@burner.fokus.gmd.de>
To: riel@conectiva.com.br, schilling@fokus.gmd.de
Cc: James.Bottomley@steeleye.com, linux-kernel@vger.kernel.org
Subject: Re: IDE/ATAPI in 2.5
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1873
Lines: 40


>From riel@imladris.surriel.com Wed Jul 17 15:37:18 2002

>> >Error handling is more than local.  Some errors, you are correct, can only be
>> >handled at the SCSI layer.  However, a large class of drivers (Think
>> >multi-path or software raid) want the ability to direct how SCSI handles
>> >errors themselves.  It is unacceptable to have SCSI all on its own retry a
>> >medium error command x times, taking minutes before the upper layers become
>> >aware anything went wrong.
>>
>> It looks like you have the wrong ideas about software raid. If you have
>> software raid, you will stack a SW raid driver just on top of the disk
>> drivers that handle the access to the real drives. The real drives first
>> do own error handling and if they cannot correct errors, the error is
>> handled inside the raid layer.

>Did you even read what James wrote ?

>When one of the disks in a RAID array develops a bad block
>it shouldn't stall the box for minutes when the error can
>be handled by simply doing the IO from other disks instead.

Is there any problem with using a ioctl() from upper layer kernel to the low 
level drivers (living under the SW raid) to reduce the number of retries to a 
reasonable value in this case?

The main design goal for UNIX as to keep it simple. There is no need for a 
complex cross layer error control.

J?rg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/