ADDITIONAL FCP_RESP IUs

Binford, Charles cbinford at ppdpost.ks.symbios.com
Thu May 4 11:46:00 PDT 1995


 ----------
>From: GFRAZIER
>To: scsi; fibre-channel-ext
>Subject: ADDITIONAL FCP_RESP IUs
>Date: Wednesday, May 03, 1995 1:48PM
>---------------------------------------------------------------------------  
 ---
>Charles Binford wrote the following note about a problem caused when the
>FCP_RESP IU is lost. My comments on his proposal follow his note.
>

original note from me (Charles Binford) deleted....

>
>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.)
>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.)
>
>
>Rather than invent yet another mechanism to eliminate exposure (2)
>it is better to use existing SCSI-3 mechanisms to eliminate both (1) and
>(2) in the first place.
>
>For exposure 1), the "Exception handling Selection Mode Page"
>(X3T10/94-190) can be used. This page allows the initiator to instruct the
>target to periodically report asynchronous events. Therefore, if an
>FCP_RESP frame is lost, others will be sent until the condition causing the
>event is resolved. This ensures that the initiator eventually is informed
>of the asynchronous event.
>

I assume "Exception handling Selection Mode Page" (X3T10/94-190)  is the 
same as what is in SPC rev 6 under the title of "Informational exceptions 
control page".  The problem I have with this approach is the way I read SPC, 
the only error I can indicate is an ASC of FAILURE PREDICTION THERSHOLD 
EXCEEDED. (section 8.3.3, first paragraph.)  The assumption is the host can 
determine what went wrong after the fact.  I am not sure that assumption is 
always true.


>For exposure 2) ACA can be used. SPC, section 7.19.1, Deferred Errors,
>specifies that an asynchrounous event can be reported by reporting a
>CHECK CONDITION and setting the appropriate sense bytes. The CHECK
>CONDITION establishes an ACA and prevents additional commands from
>causing additional damage.
>
I see no conflict between my proposal and the use of the NACA bit.  You are 
correct, exposure 2 needs ACA.  By the way. I agree with you that Kurt 
Chan's interpretation of SAM concerning this is incorrect.  (See Kurt's 
response to Giles, same discussion, different email.)

>Since existing SCSI-3 mechanisms address the problem, it is best
>to use them instead of the new FCP_RSP IUs. Microcode development, testing
>time, and the SCSI Specifications will all be simplified.
>
I agree with keeping microcode development simple.  I am not convinced your 
approach covers the issue.

While I'm here, let me respond to your comments which were in response to 
Kurt's email I referenced earlier.  (I cut and pasted your text from the 
other email.)

(Give yourself a pat of the back if you have kept up with who said 
what.....)
>>>>Giles wrote in response to Kurt in response to Giles in response to me 
:-)
>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.

Sounds good, but I haven't seen a standardized method of retrieving log 
information.  Data which is in a vendor specific format.  Maybe we should 
redirect our efforts to create a standard log page which keeps the last n 
sense buffers!

Charles.Binford at Symbios.com

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




More information about the T10 mailing list