RESEND: RE: X3T10/94-233, Revision 1: Improvements for multi-port environments

Louis Grantham Louis.Grantham at dalsemi.com
Sun Dec 18 19:01:20 PST 1994



Gene Milligan proposed an interesting set of questions related to
the identification of disks and controllers.

A number of approaches may be taken, with some examples below.

1)  	"I don't care" approach

By SCAM, by automatic Fibre Channel address assignments, or by
manual configuration, unique values are assigned to each port on a bus/fabric.
An LUN is identified during the first formatting by its serial
number using INQUIRY and VPD, regardless of port.  A volume 
identifying label using the conventions of the cooperating operating
system(s) is placed on the medium.  From then on, the system
figures out what medium is available through which port(s) and path(s)
by the volume label, not the physical path and id.

Initiators are assumed to have a unique ID and any relationship
among them is known to the initiators alone, not to the targets.

2)	Convention for relating ports and "nodes"

By SCAM, by automatic Fibre Channel address assignments, or by
manual configuration, unique values are assigned to each port on
a bus/fabric.  The set of communicating controllers within the
target subsystem has a node ID assigned and expresses that 
as its world-wide name.  Each port can either present the
same world-wide name or can present a world-wide name related
to those of the other ports by some convention.  As an example,
a node defined by an IEEE identifier may use different values
of extension but the same identifier in an IEEE extended identifier
format.  LUNs beneath the controllers are given the same
name from any port.  Using conventions like these, the
actual LUN may always be identified.

Again, initiators do not need to play the game.

In effect the first approach says that the world-wide name is only
necessary for establishing paths and the LUN's serial number and
volume label identify the LUN.  If there were multiple independent
controllers accessing the LUN, then there could be multiple
unique identifiers, but it would not really matter.

The second approach says that there is one world-wide name
for a node, where different ports may get that name or a version
of that name modified according to a known convention.

Either works.  I personally like the first, because it puts
the identification responsibility where it really belongs, on the
initiators.  It does require a LUN level unique identifier, but
the VPD serial number provides that already.



------------------  INCLUDED MESSAGE  --------------------------------------

Charles wrote: Note also, that the issue of multiple ports is irrelevant. What
you've defined
>is a set of desirable features that can be applied to any multi-initiator
>environment, irrespective of the number of ports.
 
 Maybe but, consider two fault resilient scenarios:
 
Common to each scenario is that I have paid for a disc drive which beyond a lot
of capacity, the yucky word "blazing" performance, and SCSI has two connectors
which at the buyer's option can be connected to one or two SCSI busses. When
connected to one bus it can be connected once with one SCSI ID or twice with
two SCSI ID's. The rest of the characteristics are left to the reader of SCSI
standards, drive specifications, IDENTIFY, INQUIRY, and MODE SENSE pages to
discover.
 
Scenario 1) I have plenty of money and worry a lot so I buy two host bus
adapters, lots of special software, and connect the drive up to both HBAs in
case a cable goes bad (since I walk on them a lot while I worry). Some software
will only talk to the drive through one path. An operator command is required
to switch the path with that software in the case of a failure. Other software
accesses the drive over either path depending upon bus contention.
 
Scenario 2) I don't have that much money so I buy just one HBA since this is
the normal configuration and all the software I already have understands that.
But I buy one additional turbo software package that will fire up a bigger
"blaze" and connect both of my connectors (ports) to the one bus assigning the
drive two IDs. The software that is incompatible with my turbo charger has to
have an operator configuration command to change the ID by which it accesses
the drive. The turbo charger compatible software accesses the drive with both
IDs using the algorithm for ID selection widely discussed in various Internet
forums.
 
Scenario 3) Having a passing knowledge of the state of the software art there
is no way that I will trust my data to be handled with two different IDs
simultaneously and I need to watch my spending. So I buy one HBA and two
cables. The second cable I keep hermetically sealed in a fruit jar in the
closet with the lights turned off. Only in the event of a failure will I
disconnect the troublesome connection and apply my saved cable to the other
connector on the drive hopping that the connector on the HBA is not the
problem. (These are scenarios not bad feelings about connectors.)
 
 OK. For the three scenarios how many world wide unique identifications should
the single disc drive have and how should it know when to apply them(it)?
--
Gene Milligan -- Gene_Milligan at notes
-------------------------------------------------------------------------
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at notes.seagate.com
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  
-------------------------------------------------------------------------


----- End Included Message -----







More information about the T10 mailing list