ADDITIONAL FCP_RESP IUs
cbinford at ppdpost.ks.symbios.com
Thu May 4 11:46:00 PDT 1995
>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
>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
(Give yourself a pat of the back if you have kept up with who said
>>>>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
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
Charles.Binford at Symbios.com
>gfrazier at ausvm6.vnet.ibm.com
More information about the T10