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

Charles Monia, SHR3-2/W3, 237-6757 02-Dec-1994 1645 monia at starch.enet.dec.com
Fri Dec 2 13:43:38 PST 1994


The following is extracted from Gene Millikan's response. I have rearranged 
parts of Gene's note for editorial reasons.

>For the following three scenarios,how many world wide unique identifications 
should the single disc >drive have and how should it know when to apply 
them(it)?

>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.
 
Its not clear from the above what kind of SCSI bus you're referring to. My 
original note assumed that each device had one and only one identifier that 
would be unique within the scope of the scsi "domain" and independant of the 
port through which the device was accessed. While SIP/SPI does not have such a 
requirement, I believe Fibre Channel and SSP identifiers do have this property. 
(I'm not sure about P1394 (SBP)).

Anyhow, in the three cases below, I assume a single domain-unique drive 
identifer. The issue here is not the manner in which the drive is identified but 
the way in which the paths to the drive are managed. In other words, an 
application simply declares that it wants to access drive xxx and leaves it to 
other software to figure out the path to that drive.

In each case, If we imagine a CAM-like partioning of host software with the 
device driver interfaced to something like the SIM layer, then it would be 
possible to embed the path management stuff in this lower layer. A seperate 
management interface could then be provided to adjust the path management policy 
based on the needs of a particular application or set of applications. In the 
following examples, I've assumed the existence of such a path management layer.

>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.
 
Frankly, I have a hard time imagining why an application would care whether or 
not the path is dynamic or static. As I mentioned above, I assume that the 
application simply wants to interact with a specific drive regardless of the 
physical path. In any event, one way of handling this is to have an application 
inform the path management layer as to whether or not dynamic path selection is 
allowed. For a fixed-path application, an operator interface to the path 
management software could then be provided to handle failover manually.

>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.
 
Your example assumes that port I/D == device I/D. Assuming the device I/D is 
defined as I've proposed above, however, I believe this case is a subset of 
scenario 1, above.

Yes --- I know the dual-port stuff defined for SIP/SPI works as you've 
described. As I suggested in my earlier note, however, it's inappropriate to 
propagate the SIP multiport model to newer protocols.

>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.)
 
Unless I'm missing something,  I don't see how a host cold start can be avoided 
in this case. If that's so, the host software will simply execute its startup 
routine which invokes protocol-specific code to rediscover which device I/Ds are 
present and the paths through which they may be accessed..


Thanks,
Charles





More information about the T10 mailing list