[lkml]   [2002]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: IDE/ATAPI in 2.5
At 13:32 17/07/02, Joerg Schilling wrote:
> >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
>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. As the raid layer itself will at it's top level act as if it
>was a
>disk driver, there is no relation to the block layer.

Of course it has relation to the block layer! How else are the errors going
to be passed from the disk drivers to the raid layer and then to the fs? In
an ideal world, this is what should happen so that the fs can deal with the
problem, for example on a write, the fs can mark the block as bad in the
file systems list of bad blocks, and it can change the allocation of the
block to a different location and write the data again (assuming the lower
layer cannot handle this, e.g. hardware block remapping at disk level).
Without a full error passing from the lowest to the highest level this
cannot be done and this is something that Linux needs IMO.

> >The solution is to have a stacking error handler where the error handler
> for
> >upper devices would be notified of a problem and asked for direction as
> soon
> >as it occurs.
>See above, this makes no sense.

It makes perfect sense actually. Also, see above.

> >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.

That is what you are not understanding. Ideally the block layer will be
creating the scsi, request not you. And you want to do it the other way
round. You want to create the SCSI request and pass it to the kernel for
giving it to the hardware and if the hardware is not SCSI the request will
need translation. And what other people are trying to tell you is that this
is too specific for a generic block interface and that Linux wants to have
a generic block interface that will convert requests into SCSI ones or
"plug your favourite request type here" requests depending on the attached
device driver but the interface itself is abstracted above SCSI. Ok?

> >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.

No it is not at all. SCSI is _one_of_many_ ways to talk to hardware. And as
many people have reiterated several times SCSI is _not_sufficient_ to talk
to all hardware. So there is no way in hell SCSI is going to be the generic
block interface in Linux. We now have the struct request, which is way
better than a SCSI request and is certainly going to evolve over time to be
even more powerful than it already is.

Your argument that all other OS use SCSI as the block interface is no
argument at all. Linux doesn't do what everyone else does. It does the
technically better thing, which of course can be what other OS do, but in
this case it is not. In other words, if all people jump off a cliff, are
you going to follow just because all of the others do it? I certainly
won't... (-;

Anyway, this thread has been going on for far too long. If you believe so
strongly that SCSI is generic enough for a block interface then why don't
you code that, and then submit your code to LKML? I highly suspect you will
not be able to do something that fulfills all the different device type
requirements and maintain a clean, efficient layer at the same time. Feel
free to prove me wrong by showing me the code which does it.

Best regards,


"I've not lost my mind. It's backed up on tape somewhere." - Unknown
Anton Altaparmakov <aia21 at> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on
WWW: &

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.049 / U:3.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site