A/B Port bit in Inquiry Data
cbinford at ppdpost.ks.symbios.com
Wed Feb 25 14:52:00 PST 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Binford, Charles" <cbinford at ppdpost.ks.symbios.com>
[I Cc'd the FC reflector because I feel this issue is of interest to that
side as well. Sorry for the overlap to those of us on both reflectors.]
Thanks for the response Bob. However, I don't like the answer :-). Using
the fact that "the loop is implicitly and vendor specifically identified by
the esm port" is unacceptable to me. From my point of view we have a set of
standards with a hole in them. Filling that hole with a *vendor unique*
method may work for the here and now, but I think we should drive to a
*standard* method of determining which loop is "A" and which loop is "B".
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
By the way, I curious what some of the other FC system vendors think.
Clariion, HP, Unisys, Compaq/Dec (others I probably missed...)
>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.
>> * 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
>> the mechanisms you mention below to solve the problem of mapping a path
>> 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
>> |------------------------| device (esm).
>> The SES definition of the Device element page (rev 8a, page 39) provides
>> 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
>> 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
>> drives. Valid assumption, manufacture can ensure that.
>> - The ESM device interprets the 'ENBALE BYP B' bit in the SES data as
>> 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.
>> 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
>> the remaining good path is loop 1, **but he doesn't know if he should
>> 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
>> The bit in the Inquiry seems to be a handy way to accomplish this.
>> 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
>> >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
>> >the dual port stuff was essentially thrown out some time ago. The
>> >mechanism that was put in place to address the questions that were
>> >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
>> > 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
>> > 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"
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
>> ------------- End Included Message -------------
* 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