From: Patrick Mansfield <patmans@us.ibm.com>
To: Tim Pepper <tpepper@linux.ibm.com>,
Lars Marowsky-Bree <lmb@suse.de>,
Bernd Eckenfels <ecki@calista.eckenfels.6bone.ka-ip.net>,
linux-kernel@vger.kernel.org
Subject: Re: Accessing the same disk via multiple channels
Date: Fri, 14 Feb 2003 15:37:47 -0800 [thread overview]
Message-ID: <20030214153747.A28502@beaverton.ibm.com> (raw)
In-Reply-To: <20030214140155.A5344@jose.vato.org>; from tpepper@vato.org on Fri, Feb 14, 2003 at 02:01:55PM -0800
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
next prev parent reply other threads:[~2003-02-14 23:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-13 19:49 Jurjen Oskam
2003-02-13 22:45 ` Bernd Eckenfels
2003-02-14 10:03 ` Lars Marowsky-Bree
2003-02-14 22:01 ` Tim Pepper
2003-02-14 23:37 ` Patrick Mansfield [this message]
2003-02-17 9:52 ` Lars Marowsky-Bree
2003-02-14 3:20 steve cameron
2003-02-14 16:27 ` Lars Marowsky-Bree
2003-02-14 18:17 ` Patrick Mansfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030214153747.A28502@beaverton.ibm.com \
--to=patmans@us.ibm.com \
--cc=ecki@calista.eckenfels.6bone.ka-ip.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@suse.de \
--cc=tpepper@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®