QErr and basic queuing
Gerry Houlder
Gerry_Houlder at notes.seagate.com
Mon Feb 17 18:58:01 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
*
I'd like to address the question of what is "easiest" for the target:
>With respect to Ralph's proposal to handle potential UA deadlock as it applies
>to the basic queing model, Is it really easier for a drive to abort all tasks
>on a CHECK CONDITION rather than preserving them?
>
>Initially, I had assumed without question that an implied CLEAR TASK set was
>simpler. The potential multi-initiator deadlock issue has led us in Digital to
>question whether that assumption is true under the circumstances.
If the drive has to abort tasks, it is much easier to do CLEAR TASK SET that to
do ABORT TASK SET. The basic difference is that all commands are aborted for
CLEAR TASK SET and only commands for one initiator are aborted for ABORT TASK
SET.
Example: CLEAR TASK SET can unconditionally clear all command staging queues
and stop all disk activity. ABORT TASK SET must examine each disk activity,
determine which command is it associated with, determine which initiator that
command is associated with, then decide whether to abort that activity. If the
target decides not to abort the activity, it still may need to be suspended
(lost disk rev) while all of the staging queues are examined to decide which
commands should be aborted from these queues. After all, we wouldn't want one
command to complete, then start on another command that is supposed to get
aborted while we are deciding which other commands to abort, would we? The
extra conditional testing of each command queue stage and disk hardware makes
it much more difficult to abort some commands instead of all commands.
Jim McGrath's intent for basic queuing is the simplest target activity, which
is defined as '01' in Ralph's new QErr field. The point of all this is that
once the extra complication of aborting some commands (instead of all) is added
to the drive firmware, you are only 2 or 3 lines of code away from FULL queuing
support. We don't need another gradient of queuing functionality between full
support (which already is supported by all the disc vendors if you want it) and
ATA equivalent single initiator support (which is what the basic queue model
was originally intended for).
I keep hearing that system companies want to buy the "basic queuing" drive and
use it in a multi-initiator system so they can make use of "cheaper drives".
This is the equivalent of asking for an extension to "arbitration without
attention" so you don't have to use the identify message to get multiple
initiator support. This is a bad idea -- it is better to use the already
defined extensions to full functionality instead of a crippled in-between
implementation that will end up costing just as much as the full implementation.
In Summary, keep this fact in mind: basic queuing was intended to describe a
particular simple target implementation. Let's not redefine basic queuing as
something else that doesn't match what the drive has implemented!
*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
More information about the T10
mailing list