> Hi Matt!
Hi!
> First of all Node or Port WWNs are not sufficient for this purpose. Let's
> say you have a RAID box with two controllers. Each controllser has its
> own WWN: WWN0 and WWN1. One of the controllers fails and needs to be
> replaced. The new controller has a different WWN: WWN2. But it turns out
> that the controller really wasn't bad, it just had a loose connection. So
> it's used when a controller fails on another RAID box on the same
> SAN. Now the original box has WWN1 and WWN2, but another box has WWN0 and
> WWN3. The volumes are still in the original box, but now you have a new,
> completely different set of volumes that magically appear attached to
> WWN0.
Umm, no, I can't say I entirely agree with this scenario. It's the similar to
an ethernet card- you've moved the card with the MAC address. You have to
delete the arp entries (if they haven't timed out) and update your bootparams
file because the binding of platter behind the card now has a different
address that gets to it.
In the case of an FC-AL disk (no raid box), you have something like
200000ABCDEFG Node WWN, lun 0
210000ABCDEFG Port A WWN, lun 0
220000ABCDEFG Port B WWN, lun 0
In the case of one putative RAID box, you have
200000ABCDEFG Node WWN, luns 0..N
200100ABCDEFG Port A1 WWN, luns 0..N
200200ABCDEFG Port B1 WWN, luns 0..N
210100ABCDEFG Port A2 WWN, luns 0..N
210200ABCDEFG Port B2 WWN, luns 0..N
and so on.. (haven't we argued about this before?)
where luns 0..N are either the actual spindles, or some virtually defined
storage- depends on the box.
So, if you change the card on the RAID box (or do this just in the class 3
service params), you've changed the identity of all the luns (wrt to WWNs).
Actual VPID of each lun is a separate measure, which may or may not change the
same.
And UUID labelling is yet another measure- perhaps one that is best once you
import disks (virtual or otherwise) into your system because at that point you
don't give two hoots about the address/route du millisecond.
>
> No, the only reliable way to identify a platter is through the VIPD page.
>
> > Imagion that in the future that there might be an ANSI standard filesystem
> > and an ANSI standard partition, which are connected to a heterogenious
> > SAN. But then NT goes and writes a label on the disk, then Solaris goes
> > and over writes a small part of the NT label with it's own label, and then
> > Linux comes along and over writes both of their labels with its own label.
>
> An OS has no business overwriting a disk unless it is specifically
> intructed to by the user. And if you do have multiple OSes on a SAN they
> either understand each others' label formats and everything works or they
> don't and couldn't share data that way in the first place.
Actually, real life practice about this at Veritas has convinced me that, in
fact, different systems on a SAN shouldn't even see the other systems' disks
unless they proactively share them. Have you seen the latest T10 proposals for
ACLs?
> The nice thing about using volume labels is that just about all major
> volume/filesystem formats have space (sometimes unused) for a label. The
> problem is getting the label onto an unlabeled device in the first place,
> or trying to use a device without a label such as a tape.
Amen to that.
-matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:16 EST