Nov '94 Direct Attach Disk Adhoc minutes
Kurt Chan
kc at core.rose.hp.com
Thu Nov 10 15:09:00 PST 1994
From: Kurt Chan, HP (kc at core.rose.hp.com)
To: FC, SCSI Reflectors
Subj: Minutes of 11/1/94 FC-AL Ad Hoc Meeting
Date: 11/10/94
FC-AL Direct Attach Disk Ad Hoc Meeting Minutes
11/1/94
Red Lion Stapleton
Denver, CO
There were 13 attendees:
Dal Allan, ENDL 250-1752 at mcimail.com
Charles Binford, ATT-GIS charles.binford at wichitaks.ncr.com
Kurt Chan, HP kc at core.rose.hp.com
Jim Coomes, Seagate jim_coomes at notes.seagate.com
Dave Ford, Cambex dford at cambex.com
Giles Frazier, IBM gfrazier at ausvm6.vnet.ibm.com
Gene Freeman, ATT-GIS-NCR Micro gene.freeman at colospgs.ncr.com
Stillman Gates, Adaptec stillman at eng.adaptec.com
Norm Harris, Adaptec nharris at eng.adaptec.com
Jean Kodama, QLogic j_kodama at qlc.com
Bob Snively, Sun Micro bob.snively at sun.com
Horst Truestedt, IBM truested at vnet.ibm.com
Fanny Wong, IBM fwong at vnet.ibm.com
1. SERIAL SHOOT-OUT
Bob Snively brought up the subject of using two backplane pins for
serial-in/serial-out shift registers. These registers would be used
to turn on and off LEDs, sense environmental conditions, etc. Dal and
Bob disagreed on how to use the bits (whether drive SUPPLIES or merely
RECEIVES information). Dal wanted to be able to insert a card in
place of a drive which gathers information on behalf of some
management entity, whether it's SCSI-based (e.g., SEND/RECEIVE
DIAGNOSTIC) or IP (e.g., SNMP). Dave Ford mentioned that some systems
have a separate SCSI Device on the bus which gathers this information.
RS-232 with 7 SEL lines can address any drive in a cabinet without the
need for encoding addresses serially. Dal wanted to move intelligence
requirements away from drive. It was expected that the SFF group in
Palm Springs would address some of these issues. Another scheme could
have a controlling entity performing the data acquisition/control over
point-point links to each drive (similar to a Port Bypass manager).
2. MULTIPLE PORT INITIALIZATION
With the absence of a multi-port model in SAM, a gap remains in defining
the behavior of a multi-ported Target for interoperability.
+----------------+ LOOP 1 LOOP 2 +-----------------+
| Initiator 1 Tx|<-----. .----->|Rx Initiator 3 |
| Rx|->-. | | .-<-|Tx |
+----------------+ | | | | +-----------------+
+----------------+ | | | | +-----------------+
| Initiator 2 Rx|<--' | | `->-|Rx Initiator 4 |
| Tx|->-. | | .-<-|Tx |
+----------------+ | | | | +-----------------+
+----+--+------+--+---+
| Port 1 Port 2 |
| TARGET |
+---------------------+
Consider the above system (4 hosts sharing a dual-ported drives on two
separate loops). A function is needed to reset all tasks PER PORT
without disturbing the other tasks on the second port (e.g., a second
Initiator acting on behalf of a failed Initiator). This involves a
new:
- PRIORITY RESERVE command (which breaks all other reservations)
- ABORT TASK SET OTHER INITIATOR Task Management Function
In FC, the "Other Initiator" would be identified via its WWN. Other
interfaces may have link-specific methods of identifying ports. This
would also address a system which had more than 2 initiators per port,
and more than two ports per Target.
The next question is, how does an Initiator discover who the "Other
Initiator" is? One possible solution is that, when RESERVATION
CONFLICT is returned, the Target can put the WWN of the Reserving
Initiator in the payload. Another answer that doesn't necessarily
promote interoperability is that discovery of the WWN which owns a
Reservation is vendor-unique, and should not require Target resources.
No resolution was arrived at, but Bob Snively will draft a proposal.
3. LINKED COMMANDS
Horst questioned why linked commands were prohibited, since he felt
there were applications which could benefit from them. SKIP
READ/WRITE requires linked commands (even though it is has been
removed from SCSI and is a VU command). The primary reasons linked
commands are prohibited in both the FCSI and adhoc profiles are:
- Initial implementors don't support them, and
- Added text is required to describe their behavior if they are
Allowed. Since the authors of such text are also usually the early
implementors, there is little motivation for them to document a
feature which is not implemented.
Dave Ford mentioned that typically, database management applications
won't entrust locking to Linked Commands, even though reserving an
entire drive via peer-peer semaphore passing (or RESERVE/RELEASE) is
inefficient.
A possible compromise would be:
- to keep Linked Commands Prohibited in the baseline Profile
- allow in future profiles via a Discovery mechanism (PRLI?)
- if an Initiator discovers that a Target supports Linked Commands, it
may use them. If a Target does not, the Initiator must fall back
to the baseline Profile for interoperability
- It remains up to Horst (or some other volunteer) to write up how:
o linked Command capability is discovered (and propose a new method
if none is available)
o linked commands are transmitted and completion reported
o error recovery works for linked commands
A clause will be added to clarify what Prohibited means for the
various tables, since this was a stumbling point.
4. ACA
After some lengthy discussion as to the merits of ACA, two ideas were
proposed:
1. Add IUs to make the delivery of FCP autosense reliable, or
2. Add ACA with some simplifications
Item 1 was viewed as not possible given that the Profile does not
perform Sequence Recovery or retransmission. Adding an IU which
acknowledges FCP_RSP would still not guarantee that sense information
was delivered reliably to the Initiator, since the unit of recovery in
the profile is an Exchange, not a Sequence. Futhermore, an Initiator
may not be able to determine if it's acknowledgement to an FCP_RSP was
successful in class 3 to know whether or not to reuse an OX_ID,
resulting in the requirement of a THREE-way handshake, which is
undesireable.
Item 2 looked the most promising, if we prohibit the Initiator from
attempting media access commands. Targets would be required to return
BUSY status to the faulted Initiator if it sends any media access
commands with the ACA attribute set (other Initiators receive ACA
ACTIVE status as usual, which is how you determine whether or not an
ACA condition is for you versus some other Initiator). This added
restriction does not appear to violate any existing ANSI standards,
yet greatly simplifies ACA support in both Targets and Initiators.
Note that the other added requirement is that the only actions that
can clear an ACA condition are:
1) CLEAR ACA Task Management fucntion
2) TARGET RESET Task Management function
3) LIP hard reset
4) Powerfail of the Target
An error in ver 1.00 of the profile was corrected (Request Sense with
ACA attribute set does NOT clear an ACA condition).
5. MEETING SCHEDULE
Next meeting is Dec 5 in San Jose at the Red Lion (concurrent with
ANSI week). We'll be in the Board Room from 830-5p, although I expect
to be able to adjourn early. The only preplanned agenda items will
be:
o Review Vince Cavanna's test results for the Hirosi vs Coax
connectoring and discuss external physical layer issues in general
o Review ver 1.10 of the Profile. In particular,
- ACA
- Annex A (proposed FC-PH/FCP changes)
- Initialization
o Future meeting schedule (esp re: January in Lake Tahoe)
I'll announce when version 1.10 is available on-line (11/18 target).
More information about the T10
mailing list