A/B Port bit in Inquiry Data
Binford, Charles
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
*standard* solution.
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 -------------
>
>
*
* 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