On Fri, 25 Jun 1999, Matthew Jacob wrote:

> > On Thu, 24 Jun 1999, Matthew Jacob wrote:
> > 
> > > Specifically in this case a Node WWN for fibre channel fabrics that does
> > > not depend upon an assigned WWN in any particular Fibre Channel card
> > > (multipathing might make it desirable to have a synthetic Node WWN that
> > > can also be passed to partner systems in  a failover configuration).
> > 
> > Matt,
> > 
> > We've been hashing this issue out quite a bit.  Since a Fibre Channel card
> 
> I thought you might be!
> 
> > is by definition a fibre channel controller, each card should have a
> > unique WWN that is used for the node WWN.  If you swap a controller, the
> > node WWN should change.
> 
> 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.

> > The concept is that for SCSI disks and RAID boxen at least, the unique
> > identifier is the LUN WWN, which is the unique label for the data
> > contained on that LUN.  The LUN WWN is 128 bits wide is generated from a
> > combination of the controller's node WWN and a timestamp, and is lost when
> > the LUN is destroyed.
> 
> 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.

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. 

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.

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

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me