Date: Sun, 03 Oct 1999 11:22:37 -0700 From: Mike Smith <mike@smith.net.au> To: Justin Gibbs <gibbs@plutotech.com> Cc: hackers@FreeBSD.org Subject: Re: SCSI disk naming problem Message-ID: <199910031822.LAA06823@dingo.cdrom.com> In-Reply-To: Your message of "Sun, 03 Oct 1999 11:13:49 MDT." <199910031713.LAA30518@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 'Path based names' do not deal with systems that have multiple
> > > paths to the same device. For example, if I have two host adapters
> > > talking on the same bus for redundancy, which name to I give to the
> > > devices on the bus?
> >
> > That depends on how you're handling the redundancy; either you do it
> > inside the kernel in which case the resulting device has a virtual
> > path, or you do it outside in which case you have two paths which point
> > to the same device.
>
> I don't see how it helps to have a virtual path of any kind.
It's the logical way to hide the physical path information from the
consumer if you're predicating that path information is the sole
identifier for the device. In the context of "reliable physical paths"
it serves the same basic purpose as using a virtual name for a mirrored
disk array; you have a virtual entity that is transparently reliably
backed.
> In the
> case of fully connected I/O, everything would have a virual path and
> the path information would be useless to the user. I much prefer the
> idea of exporting each unique device to the user, allowing them to
> query path information and perhaps select path use behavior, but
> default to having the peripheral driver for the device handle most
> routing behavior automagically.
In other words, you prefer fully virtual paths. ('da0' is a virtual
path, for example.)
> I would expect most people to want
> the system to fail-over to anouther route to the device instead of
> requiring manual intervention on the part of the process using that
> device.
Naturally, which is where the virtual path comes into it. The
argument that's being proposed at the moment is just that where there
is a 1:1 mapping between the virtual and physical paths the physical
path should be exposed for user convenience. Personally I'd prefer an
option to camcontrol that would allow you to recover the physical path(s)
and just leave it at that.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org
\\ and he'll hate you for a lifetime. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910031822.LAA06823>