On Fri, 28 Apr 2000, Eduardo Horvath wrote:
: 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.
:
: No, the only reliable way to identify a platter is through the VIPD page.
This is not quite correct. A Fibre Channel PLOGI will identify both the
Port's WWN (P_WWN) and the Node's WWN (N_WWN) on whose behalf the port is
logging in. The Login acceptance carries the same information for the
other side of the connection.
In your scenario, WWN0 is P_WWN0 and should be recognized as having been
moved from N_WWN0 to N_WWN1, thereby creating a different path.
Your ultimate assertion is more correct however, in that the controller's
N_WWN is not directly tied to the platters or the storage thereon.
: 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.
They may not be able to share data/targets, but there are multiple
solutions allowing them to share the SAN.
-Kevin
-
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:15 EST