Date: Fri, 25 Jun 1999 12:32:27 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: eeh@netbsd.org Cc: freebsd-hackers@FreeBSD.ORG, tech-kern@netbsd.org Subject: Re: System unique identifier..... Message-ID: <Pine.BSF.4.05.9906251221480.38018-100000@semuta.feral.com> In-Reply-To: <Pine.GSO.3.95.990625115247.12248B-100000@jericho>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > Really? Couldn't the Port WWN change and the Node WWN stay constant? I > > mean, yes, for FC controllers that have WWN in the 0x2XXXXXXXXXXXX range, > > the Node WWN is 0x20... and the Port is 0x22... but it seems like this is > > a soft relationship- you *could* have Port && Node unique for each card, > > but then that requires all fabric clients to know (via some other > > arbitrary mechanism) that distinct WWNs are really the same 'box'. > > Existing FC RAID boxes have multiple controllers, each with a different > WWN. The port WWN is derived from the Node WWN. The Node WWN is in the > controller's PROM. In theory, when you swap one controller, the other > controller could remember the old node WWN and give it to the new > controller, but: > > If you swap both controllers, who's going to remember the old node WWNs? > > If you pull one controller from one box and stick it into another box, > then plug in a replacement controller into the first box, if the > replacement controller takes over the previous WWN, you could end up with > two different devices with the same WWN. I agree that this would be chaos, but you're using implementation to argue architecture. I'm thinking of a SANs of FreeBSD/NetBSD/Linux/Solaris boxes running simultaneous target/initiator mode on Fibre Channel. I can use WWN info wired into a specific card (whether it's the Port or Node WWN is solely at my discretion when I fire up the f/w and tell it what it it is), or I can choose something different entirely as the source of a WWN. As long as it's guaranteed unique in this domain, it's an acceptable design. > > Sure. That's reasonable enough, but not necessarily a problem that needs > > solving. The LUN isn't interesting in that what you want a known Node WWN > > for (routed to via multiple Port WWNs) so that when you construct the > > addressing to some physical box you, and intervening FC switches, can get > > the frame there. Beyond that, multilevel LUN numbers seem adequate for > > *within box* addressing, and then whatever volume management software > > needs to look at > > Thing is, the LUN is reachable through both controllers, each has a > different Node (and port) WWN. The FCP protocol layer should be > addressing these entities by LUN WWN. This means that it is responsible > for identifying the individual entities and establishing the mapping of > LUN WWN to associated Node WWNs. For boxes that support LUN WWN.... > > Thus multipathing needs to be done both at the FCP layer to handle the LUN > WWN <-> Node WWN mapping, as well as lower levels to deal with different > routes to different ports. > > Now you could allow the Node WWN to migrate between different physical > machines or controllers when handling failover, but if you did that you > would be violating the spirit, if not the letter of the Fibre Channel > specifications. This is a valid point- I'm going to mull about this some more then. > > Having said all that, I am a strong proponent of dumping all these silly > WWNs in the trash and embedding a volume identifier in the disklabel > itself. You really don't care all that much what device you're talking to > most of the time. What you really want is your data, so label the data > not the hardware. That's sct's (tweedie's) notion too. The answer to this is "Sometimes you *do* care about not only which specific one of N replicate data sets you have, and sometimes you even care about which path you took to get it". > > > At any rate, the WWN issue is just one use of this identifier. > > While the idea of a unique system identifier may have merit, I don't think > that generating node WWNs is an appropriate use for it. So, when are you gonna fix socal in Solaris to not use localetheraddr and a blind usage of hba instance (which has at least two level 2 bugs waiting to happen any day now) as a seed for cons'ed up WWNs? (*now* who's using implementation to argue architecture? :-;) -matt 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?Pine.BSF.4.05.9906251221480.38018-100000>