From owner-freebsd-arch Fri Jul 21 15: 4:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1B8D137C171; Fri, 21 Jul 2000 15:04:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA14751; Fri, 21 Jul 2000 15:03:49 -0700 Date: Fri, 21 Jul 2000 15:03:27 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: wilko@freebsd.org Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <20000721233903.A21976@freebie.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > These are 64 bit WWNs. For example the CPQ HSGxx StorageWorks arrays > present a 128 bit extended WWN for each of the LUNs they can present to > the FC-AL/fabric they are connected to. A total of 128 LUNs can be presented > via 2 host port pairs (a pair of ports acts as a failover pair in case one > has redundant array controllers; of each controller one port is part of one > pair). The FC cards only support 64 bit WWNs- these are part of the class 3 service paramaters. The 128 bit WWNs *may* be available- but you have to use VPD info to get at them- all of which is do-able and should be one. > > Serial numbers (IIRC) that are presented by a LUN are all the same: the ser# > of the HSG raid controller. And are therefore quite useless to the problem > at hand. That's why there's a lun qualifier after the serial number. The same thing, btw, applies to 64 bit WWNs- they're for target, not the lun. > So, I think it would be nice if 128 bit WWN could also be handled. Yes, I agree. > A, very desirable IMO, side effect is that once this is done correctly one > can use the information for use in a dual-rail driver. For HA systems having > a dual connection to a RAID box becomes rather common these days. Using > the WWNs it is relatively easy to spot multiple paths to a single LUN/disk. Yes! Yes! Yes! Exacto-mundo! > ... > The problem I see is the fact that I have yet to meet someone who can > correctly transcribe 64 bit numbers, let alone 128bit ones.. :-( But there > is only so much you can do about that problem. Yes- this is indeed a problem. But I would view this as just the need for a tool- possibly Tcl/Tk with X extensions, to allow you to do volume selection which would be responsible for adding things to fstab. But do people have any plus/minus feelings about linking mount with libcam so it can try and translation information? I also feel that it would be better if this were less device class specific, but maybe that waits the full devfs (which I don't expect to see in 5.0). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message