On Wed, 17 Jul 2002, Joerg Schilling wrote:
> >From James.Bottomley@SteelEye.com Tue Jul 16 16:33:32 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.
> >But the new scheme allows that. The block queues accept translated requests
> >(that's really what sg does).
>
> A SCSI request is _not_ a translated request. It is the real request itself.
> You usually even cannot translate a SCSI request into something else.
This suggests we shouldn't put all kinds of non-scsi devices
under the SCSI stack and should have a more generic block and
character device layer instead ...
> >But you're still too SCSI transport specific. The ongoing goal is to make the
> >physical transport protocol an adjunct to the Linux internal transport (the
> >struct request) so that we can treat all block/character devices on an equal
> >footing.
>
> You seem to forget that all main control is done via SCSI commands. You
> are too anti SCSI wthout a real reason.
... and here you contradict what you said above.
Will you do the honours or are you waiting for somebody else
to godwinate the thread ?
regards,
Rik
-- Bravely reimplemented by the knights who say "NIH".http://www.surriel.com/ http://distro.conectiva.com/
- 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/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:23 EST