Question on RECOVERED ERROR handling
Gene Milligan
Gene_Milligan at notes.seagate.com
Tue Aug 8 05:25:19 PDT 1995
Charles wrote:
>These look contradictory to me. In the case of a deferred
>error, the standard seems to require the logical unit to
>terminate the command without doing any work. Whereas the
>description for RECOVERED ERROR implies that the associated
>command has completed successfully.
I don't think they are contradictory at all. The two commands in question are
not the same command and hence the descriptions are addressing two different
tasks. The command (task) that is not being executed is the one that is in this
case merely a surrogate to carry the deferred status back to the host
(initiator) for the command that was reported to have already completed without
error (but in spite of that assumption in the fullness of time turned out to
have an error).
From a practical standpoint the concept of reporting recoverable deferred
errors is a questionable one to me. I assume most applications would have no
way of dealing with a deferred recoverable error since there is no specific way
to identify the command with which it is associated. However they would have
useful things to do with a deferred unrecoverable error since the device needs
some form of attention. (One exception to the uselessness of deferred
recoverable errors might be a deferred report that a write resulted in a
reassigned block for systems that wish to keep track of deallocation events.) A
deferred error is modest way of implementing asynchronous event notification
and does not relate at all to the command it grabs as a vehicle.
Gene
More information about the T10
mailing list