SCSI-3 FCP ACA/QErr abort process

Gerry Houlder Gerry_Houlder at notes.seagate.com
Mon Aug 25 09:53:58 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
*
Joseph Carl Nemeth's last message had the following point:
>but I am very 
>curious as to why this was defined in this fashion. It seems to me that the 
>target should never, ever, EVER be allowed to abort a command under any 
>conditions.
There is a lot of history here. The QErr bit was intended for use in SINGLE
INITIATOR parallel SCSI systems. The idea is that a write command may fail
with a CHECK CONDITION status and a following read command (which is
already sent and in the drive's command queue) that reads the same data
will therefore return the wrong data. Since all of the later "aborted" commands
are for the same initiator that got the CHECK condition, that initiator knows 
that
all commands still outstanding have to be resent. The initiator didn't have to
clean up anything for those commands first, it just resends them.
This is known to be very troublesome in a multi-initiator system. This is why a
recent proposal by Charles Monia replaced the QErr bit with a two bit field to
define another option. The new option is that only commands from the same
initiator are aborted and not any commands from other initiators. This gets the
resulting action in a multi-initiator system similar to the action in a single
initiator system for those initiators that insist on off loading this command
abort work to his targets.
It is OK for you to think that targets shouldn't be required to do silent aborts
on commands as part of error handling. Most sane people agree with you.
Initiators can avoid the type of problem that the QErr feature was designed
to protect against by not allowing a read command to access an area with
an outstanding write command until the write command has completed.
This isn't effective for multi-initiator systems unless the initiators cooperate
on these issues or use RESERVE and RELEASE commands when
important updates are being made to the data (do you ever make
unimportant updates?). 
*
* 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