From owner-freebsd-hackers Sun Oct 3 10:15: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 17CA814DB5 for ; Sun, 3 Oct 1999 10:15:05 -0700 (PDT) (envelope-from gibbs@pluto.plutotech.com) Received: (from gibbs@localhost) by pluto.plutotech.com (8.9.2/8.9.1) id LAA30518; Sun, 3 Oct 1999 11:13:49 -0600 (MDT) (envelope-from gibbs) From: Justin Gibbs Message-Id: <199910031713.LAA30518@pluto.plutotech.com> Subject: Re: SCSI disk naming problem In-Reply-To: <199910031648.JAA06411@dingo.cdrom.com> from Mike Smith at "Oct 3, 1999 9:48:42 am" To: mike@smith.net.au (Mike Smith) Date: Sun, 3 Oct 1999 11:13:49 -0600 (MDT) Cc: jin@george.lbl.gov, hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > '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. 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. 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. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message