On Fri, Feb 14, 2003 at 02:01:55PM -0800, Tim Pepper wrote:
> On Fri 14 Feb at 11:03:16 +0100 lmb@suse.de done said:
> >
> > Doing it in the SCSI layer has the advantage of not being constrained to block
> > devices, but also working with tapes. Oh well, we'll see ;-)
>
> Tape needs special multipathing logic. Don't you think moving
> multipathing to the mid-layer requires the mid-layer to know much more
> about the upper layer and muddles up the scsi stack's layering? To keep
> multipathing high and generic we need better error reporting than the
> one bit that hits the md layer in 2.4...
>
> t.
If we want to be able to retry a tape read/write that actually might have
made it to the media it requires special handling (as compared to a random
access device) no matter where we put multi-path.
The scsi mid-layer is a bit muddled up already (but getting better).
Adding multi-path there does not make it worse. Much of the same code that
cleans up the scsi mid-layer also makes scsi multi-path easier (that is,
recent changes cleaning up the scsi mid-layer make it easier to implement
scsi multi-path).
Generic multi-path without the lower levels knowing anything can waste a
lot of resources. For example, for each extra path to a block device
(disk) we end up with an extra sd plus associated data structures, and an
extra scsi_device including multiple request queues.
The main thing scsi multi-path needs to know is that multiple nexuses
(i.e. host/channel/target/lun) correspond to the same unit. This has no
interactions with any upper layer drivers, and limits what the upper layer
drivers (and users) have to work with, and more closely matches the layout
of the actual hardware.
-- Patrick Mansfield
-
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 : Sat Feb 15 2003 - 22:00:59 EST