QErr and basic queuing
Charles Monia 237-6757
monia at AM.SHRMSG.SHR.mts.dec.com
Tue Feb 18 13:36:36 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* Charles Monia 237-6757 <monia at AM.SHRMSG.SHR.mts.dec.com>
*
Hi Gerry:
Your response discusses the issue of selectively aborting tasks, which I agree
might be more complex than desirable.
I guess my question should have been:
"In response to a CHECK CONDITION, is it easier for the drive to abort all
tasks or no tasks."
With regard to addressing UA deadlock, it's my understanding that the O/S's I'm
concerned with could live with drives that support the all or none behavior. In
that case, we'd always specify "none" (ie. Qerr = 0).
Thanks,
Charles
Gerry holder writes:
> * 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
>
************************************************************ ***** *
* Charles Monia, Storage Architecture Group *
* Digital Equipment Co. Internet: charles.monia at shr.mts.dec.com *
* Tel: (508) 841-6757 X400: c=US; a=MCI; o=Digital; ou=SHR *
* Fax: (508) 841-6100 *
************************************************************ ***** *
*
* 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