> > 
> > 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