Date: Fri, 21 Jul 2000 15:03:27 -0700 (PDT) From: Matthew Jacob <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? Message-ID: <Pine.BSF.4.05.10007211457470.8451-100000@semuta.feral.com> In-Reply-To: <20000721233903.A21976@freebie.demon.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10007211457470.8451-100000>