Question on RECOVERED ERROR handling
Gerry_Houlder at notes.seagate.com
Fri Aug 4 06:50:23 PDT 1995
The wording you just included in your message describes situation (c):
(c) Command A (the one for which the Deferred Recovered Error information was
reported) completed successfully because the error recovery action was
successful. This command had previously reported GOOD status for itself. In
this case no error recovery action is needed for that command.
Command B (the command that ended with CHECK status, deferred error sense)
is not executed. A recovery action for this command is needed.
Thus the statements you included in your message aren't contradictory, those
statements refer to the results of different commands. The wording of the
standard doesn't necessarily reflect actual implementations, however, so your
question is valid.
Note that the wording of the standard requires "command B" to be aborted even
though it could be successfully executed. This can cause a lot of bother for a
driver when deferred errors occur. Thus a target designer should minimize the
reporting of deferred errors.
STEPPING ONTO SOAPBOX ...
In my opinion, recovered errors (things that will never require a recovery
action) shouldn't be reported as deferred errors. This will cause recovered
errors to be swept under the rug and not reported, but if the host really cared
about recovered error reports it shouldn't be doing "immediate" commands.
Deferred errors should only be used to report unrecovered errors (things that
will always require a recovery action).
More information about the T10