Subject: Re: System unique identifier.....
To: None <email@example.com>
From: Matthew Jacob <firstname.lastname@example.org>
Date: 06/25/1999 12:32:27
> > 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
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? :-;)