ADDITIONAL FCP_RESP IUs

Kurt Chan kc at core.rose.hp.com
Wed May 3 18:33:27 PDT 1995


From:  Kurt Chan
To:    FC, SCSI Reflectors
Subj:  Re: FCP_RSP confirmation and ACA
Date:  Wed May  3 18:29:09 PDT 1995

| 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.)

I think "asynchronous event" may be misleading terminology.  An
FCP_RSP which demands confirmation is not asynchronous - it is a
Solicited Control IU.

| 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.)

Yes, ACA=1 can solve this, but it needs the lack of FCP_RSP
confirmation to keep the ACA condition persistent.

If the Target implements ACA=1, it cannot clear the ACA condition
until FCP autosense is successfully delivered.  Until the confirmation
is received from the faulted initiator, it is important that the
Target NOT clear the ACA condition merely because the FCP_RSP has been
retried a "vendor unique" number of times.

The reason is that the initiator may be a member of an OPS quorum
which has decided to remove itself from the quorum, but may still have
I/Os queued in the adapter/fabric/controller.  It is important that
these queued I/O's not be executed. The lack of confirmation will ensure
that the ACA condition persists, and that these I/Os will be returned
with ACA Active status until CLEAR ACA, hard reset, etc occurs.

Without a confirmation requirement, the Target will not know that
autosense was delivered to a "dead" host, and will clear the ACA
condition and the associated sense data as FCP_RSP is transmitted (but
unsuccessfully received). 

-------

Ref: SAM 6.6.1.2 

"...the logical unit shall also clear the associated ACA condition
 upon the return of sense data by means of the autosense mechanism..."
          ^^^^^^
Without an FC-4 response, the "return" of sense data from the logical
unit's perspective means as soon as the FCP_RSP frame is transmitted.

-------

Ref: SAM 6.6.4

"Sense data shall be preserved by the logical unit for the initiator
 until it is transferred by one of the methods listed below...
             ^^^^^^^^^^^.
   .
   c) Autosense delivery"
                ^^^^^^^^
Without an FC-4 response, the term "transferred" and "delivery" from
the logical unit's perspective mean as soon as the FCP_RSP frame is
transmitted.  

-------

Both of these have been sore spots for some time with FCP and for good
reason:  without a confirmation mechanism for FCP_RSP, it is
impossible for an FCP lun to comply with SAM in the correct fashion.
Charles Monia has pointed this out several times when we attempted to
modify SAM to accomodate FCP's shortcomings...  ;-) 

I believe the intent of SAM is for the LUN to hold onto the ACA
condition and the associated sense data until it has CONFIRMED
delivery of the sense data to the faulted initiator.  Perhaps some
more explicit wording to replace "transferred", "delivery", and
"return" in the above clauses would make this more clear.  (Do I need
to submit a public review comment? 8-(.

Regards,
Kurt Chan 
kc at core.rose.HP.com





More information about the T10 mailing list