MRIE behavior in SPC-2 vs SSC

Gene_Milligan at notes.seagate.com Gene_Milligan at notes.seagate.com
Mon Jun 7 17:15:47 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* Gene_Milligan at notes.seagate.com
*
<< The reason for this is that we will only report a 'recovered
error' on commands that the initiator would normally expect to see a
'recovered
error' (e.g., reads and writes) and that type of command may not be the
'next'
command.>>

     SPC allows the above behavior but the above behavior is vendor
specific. SPC does have rules regarding the state of the candidate command
for a deferred error report that in some cases makes it not eligible as a
surrogate for a deferred error.

     Your note caused me to look at the deferred error definition in SPC-2.
I find there are changes to it that make it less clear than SPC and I think
there is now at least one error.

<<If an application client on an initiator other than the causing initiator
attempts access to the particular function
or subset of data associated with the deferred error and TST=000b (see
8.3.4), the command attempting
the access shall be responded to according to the requirements in SAM-2. If
an application client on an
initiator other than the causing initiator attempts access to the
particular function or subset of data
associated with the deferred error and TST=001b, the command attempting the
access shall not be blocked
by the deferred error and the cause of the deferred error may result in an
error being reported for the
command attempting the access;>>

     I have not checked to see if the above wording is the same as was in
my proposal. If it was blush. I can not be sure what this statement
requires. If I guess correctly I think it should be changed to "If an
application client on an initiator other than the causing initiator
attempts access to the particular function or subset of data associated
with the deferred error  the access shall be responded to according to the
requirements in SAM-2. If an ACA or CA is pending and TST=000b (see 8.3.4),
the command attempting the access is blocked.  If an ACA or CA is pending
and TST=001b, the command attempting the access shall not be blocked.
However the cause of the deferred error may result in an error occurring
and reported for the command attempting the access;"

<<NOTE 32 Deferred errors may indicate that an operation was unsuccessful
long after the command performing the
data transfer returned GOOD status. If the application client is unable to
replicate or recover from other sources
the data that is being written using buffered write operations,
synchronization commands should be performed
before the critical data is destroyed in the host. This is necessary to be
sure that recovery actions may be taken if
deferred errors do occur in the storing of the data. If AER is not
implemented, the synchronizing process should
provide the necessary commands to allow returning CHECK CONDITION status
and subsequent returning of
deferred error sense information after all buffered operations are
guaranteed to be complete.>>

     This is tough to follow. Best solution is always to delete a note. But
alternatively change it to: "NOTE 32 Deferred errors may indicate that an
error occurred long after GOOD status was returned. The application client
should attempt to determine which data, if any, has been lost and take
appropriate recovery actions."

     The current not in addition to being difficult to understand includes
three assumptions that do not seem correct to me. There is an implication
that a deferred error can be associated with a specific command. There is
an implication that only commands that transfer data can result in a
deferred error. There is an implication that a deferred error can only
result from a command.

Gene




*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list