A/B Port bit in Inquiry Data

Larry Chen larryc at maxstrat.com
Wed Feb 25 18:02:59 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Larry Chen <larryc at maxstrat.com>
*

On Wed, 25 Feb 98 16:52:00 CST  Binford, Charles wrote:
>

<cut>


>Today I feel the easiest and best solution to this problem is the A/B port 
>bit in the Inquiry.  I am more that willing to listen to other ideas on how 
>to solve the problem.  I'm not wanting to push the A/B bit, I just want a 
>*standard* solution.
>
Hi Charles,

>From my prespective, the A/B bit is already a defacto-standard started
by a BIG disk vendor. I plan to use it until a better standard solution
is found.

>By the way, I curious what some of the other FC system vendors think. 
> Clariion, HP, Unisys, Compaq/Dec (others I probably missed...)
>
>Charles Binford
>Symbios Inc.
>
>
>
> ----------
>>From: Bob Snively
>>To: cbinford; T10
>>Subject: Re: A/B Port bit in Inquiry Data
>>Date: Tuesday, February 24, 1998 4:34PM
>>
>>---------------------------------------------------------------------------  
> ---
>>See my recommendation below.
>>
>>Bob
>>
>>>
>>> * From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>>> * "Binford, Charles" <cbinford at ppdpost.ks.symbios.com>
>>> *
>>>
>>> Hello Bob,
>>>
>>> I agree with your comments in general.  However, I don't see how I can 
>use
>>> the mechanisms you mention below to solve the problem of mapping a path 
>to
>>a
>>> device to either port A or B in SES.  Consider the following:
>>>
>>>
>>>        |--------------|
>>>        |     Host     |
>>>        |              |  Host with 2 FC adapters - hba1 and hba2
>>>        |              |
>>>        | hba1    hba2 |
>>>        |---+------+---|
>>>            |      |
>>>           /        \
>>>   Loop 1 /          \ Loop 2
>>>         /            \
>>>   |------------------------|
>>>   |  esm device            |
>>>   |                        |   FC JBOD with 5 dual-ported drives
>>>   | d1   d2   d3   d4   d5 |   (d1 - d5), plus a dual ported enclosure
>>> service
>>>   |------------------------|   device (esm).
>>>
>>>
>>> The SES definition of the Device element page (rev 8a, page 39) provides
>>the
>>> ability to enable and disable the bypass for port A and port B
>>> independently.  In my example above, I'd like to use SES to bypass ports
>>> connected to loop 2 (say a port's receiver broke and brought the loop
>>down).
>>>  Given the picture, the host would issue an SES command via hba1, across
>>> loop 1, to the esm device.  In the SES data, the host would indicate that 
>
>>> the esm should bypass the 'B' ports of the drives.
>>>
>>> Now, lets consider the assumptions I just made:
>>>
>>>  - The "loop 2" connector on the JBOD box is connected to the 'B' port of
>>the
>>> drives.  Valid assumption, manufacture can ensure that.
>>>
>>>  - The ESM device interprets the 'ENBALE BYP B' bit in the SES data as
>>being
>>> associated with loop 2.  Again, a valid assumption because it is under
>>> control of the JBOD manufacturer.
>>>
>>>  - Loop 2 is connected to hba2. INVALID assumption.  The *user* ran the
>>> cables from the JBOD to the HBAs, software has no way to know if loop 2
>>> (port B on the drives) is connected to hba1 or hba2.
>>>
>>>
>>
>>The trick here is that the loop is implicitly and vendor specifically
>>identified by the esm port, which is identified by the appropriate report
>>bit.  Hope that is some help.
>>
>>Bob
>>
>>> Another way to look at the same problem is this.  Assume that loop 2 goes 
>
>>> down for the same reason (broken receiver in a port).  The host knows 
>that
>>> the remaining good path is loop 1, **but he doesn't know if he should 
>tell
>>> the esm device to bypass loop A or loop B ports**.  There must be some
>>> reliable way to know if hba1 is connected to port A or port B of the 
>drive.
>>>
>>>
>>> The bit in the Inquiry seems to be a handy way to accomplish this.
>>Granted,
>>> it is limited to only two port devices, but then again so is SES's Device 
>
>>> element definition.
>>>
>>> If you have another way to solve the problem I'd love to here it.
>>>
>>> Charles Binford
>>> Symbios
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  ----------
>>> >From: Bob Snively
>>> >To: T10 at symbios.com
>>> >Subject: Re: A/B Port bit in Inquiry Data
>>> >Date: Monday, February 02, 1998 5:51PM
>>> >
>>> >* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>>> >* Bob Snively <Bob.Snively at Eng.Sun.COM>
>>> >*
>>> >
>>> >As a reminder of the mechanism that was selected to handle port 
>management,
>>> >the dual port stuff was essentially thrown out some time ago.  The
>>> >mechanism that was put in place to address the questions that were 
>raised
>>> >by dual ports were two:
>>> >
>>> >    Persistent reservation allowed establishment of reservations for
>>> >    multiple initiator/port environments and allowed those initiators
>>> >    in charge of the configuration to eliminate failing initiators from
>>> >    the permitted group.  While there is still some work going on in 
>this
>>> >    area, the principles are sound.
>>> >
>>> >    The Device ID "page" in the Inquiry Data included a node identifier.
>>> >    After SPC, but before SPC-2, this node identifier was extended to 
>allow
>>> >    multiple identifiers in a single field.  One of the identifiers was
>>> >    intended to identify the port uniquely, providing all the tools that
>>> >    were necessary to complete the management of multiple port devices.
>>> >
>>> >For that reason, it is certainly unclear to me that any additional
>>> >flag information is required to properly identify and manage multi-port
>>> >devices, including large RAID devices.  It is even less clear to me that
>>> >we want to drag in either an "a/b" concept or an "active/alternate"
>>> concept.
>>> >
>>> >Bob
>>> >
>>> >
>>> *
>>> * For T10 Reflector information, send a message with
>>> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
>>>
>>> ------------- End Included Message -------------
>>
>>

-------------------------------------------------------
Larry Chen             Tel: 408.383.1600 (x116)
MAXSTRAT Corporation   Fax: 408.383.1616
801 Buckeye Court      E-mail: larryc at maxstrat.com
Milpitas, CA 95035     URL: http://www.maxstrat.com/
-------------------------------------------------------


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list