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