NEW FCP_RESP IUS

GFRAZIER at AUSVM6.VNET.IBM.COM GFRAZIER at AUSVM6.VNET.IBM.COM
Thu May 4 06:47:52 PDT 1995


Carles Binford recently proposed two new FCP_RESP IU, and I wrote:

 | These new FCP_RESP IUs elimate only part of a data integrity exposure. To
 | completely eliminate the exposure, both of the following must be ensured.
 |
 | 1) Ensure that the initiator is informed about the asynchronous event.
 |    (Charles's proposal eliminates this exposure adequately.)

Kurt Chan then replied:
>I think "asynchronous event" may be misleading terminology.  An
>FCP_RSP which demands confirmation is not asynchronous - it is a
>Solicited Control IU.

Charles's proposal stated that the problem he was solving was the loss of
status NOT ASSOCIATED WITH THE COMMAND. This status could be either an
asynchronous event or a deferred error such as a loss of cached write
data. My previous note described a standardized method of ensuring delivery
of asynchronous events. For ensuring delivery of deferred errors, it would
be just as good for the target to use the following procedure:

1) Send the FCP_RESP frame with the deferred error.
2) Log the defferred error (in this case, the loss of the cached data).

If the FCP_RESP was lost, the initiator would discover it after a ULP
timeout and it could then read the log to discover that the cached data was
lost. Again, this procedure uses existing SCSI-3 procedures--no
reinvention.

In response to my other comment:
 | 2) Ensure that the problem caused by the asynchronous event is not
 |    compounded by additional commands received from the initiator before it
 |    knows about the event.
 |    (Charles's proposal does not prevent this from occuring.)
Kurt then wrote:
 "Yes, ACA=1 can solve this, but it needs the lack of FCP_RSP
  confirmation to keep the ACA condition persistent."

I do not think this is correct. ACA remains in effect until it is
explicitly cleared by the initiator with a CLEAR ACA TM function.

Kurt also wrote:
" If the Target implements ACA=1, it cannot clear the ACA condition
 until FCP autosense is successfully delivered."

I do not think this is correct either. The initiator can clear the ACA
at ANY time by a CLEAR ACA TM function.

Kurt also quoted SAM, 6.6.1.2, which states:

>"...the logical unit shall also clear the associated ACA condition
> upon the return of sense data by means of the autosense mechanism..."

This is true for NACA=0--the case where ACA is NOT used. For NACA=1 (USE
SCSI-3 ACA), this statement does not apply.

Therefore I still don't see the need to complicate SCSI-3 or FCP with these
additional FCP_RESP_CONFIRM IUs.

Giles Frazier
IBM Austin
gfrazier at ausvm6.vnet.ibm.com




More information about the T10 mailing list