Question on RECOVERED ERROR handling

[Gene Milligan]

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