James Bottomley wrote:
if you specifically set TAS=1 you're giving up the right to know what
caused the command termination. With insufficient information, it's
really unsafe to simply retry, which is why the mid layer just returns
TASK ABORTED as an error. If you set TAS=0 we'll get a check
condition/unit attention explaining what happened (usually commands
cleared by another initiator) and we'll explicitly do the right thing
based on the sense data.
Actually, having TAS=1 has a considerably advantage over TAS=0 from
error recovery point of view. With TAS=1 all aborted commands are
supposed to be returned immediately to all affected initiators. With
TAS=0 affected initiators will not receive any notification about
aborted commands, only COMMANDS CLEARED BY ANOTHER INITIATOR UA will be
established. So, they will know about that only after there will be
timeout for their commands.
Thus, with TAS=1 almost immediate error recovery is possible, but with
TAS=0 error recovery is possible after timeout, which for SSC devices
can be hours.
But having TAS=1 is legal, right? So it should be handled well. If
TAS=0, TASK ABORTED can't be returned, it would be illegal. So, TASK
ABORTED status can only be returned with TAS=1.
Driving with your handbrake on is legal too ... that doesn't mean you
should do it ... and it certainly doesn't give you a legitimate
complaint against the manufacturer of your car for excessive brake pad
wear.
We handle TASK ABORTED as well as we can (by failing it). For better
handling set TAS=0 and we'll handle the individual cases according to
the sense codes.
After some digging in SAM/SPC I've figured out that TASK ABORTED status
can be returned exactly in the same circumstances as COMMANDS CLEARED BY
ANOTHER INITIATOR UA, it only depends from TAS bit, which way of the
notification is used. So, TASK ABORTED status carries the same
information as COMMANDS CLEARED BY ANOTHER INITIATOR UA and should be
handled at the same way. I.e., if for COMMANDS CLEARED BY ANOTHER
INITIATOR UA the affected commands are restarted, they should be
restarted for TASK ABORTED status as well.
Vlad
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
