Mulit-Initiator Task Set (Queue) Full vs Busy responses.

George M Ericson ericson at
Sat Jun 27 05:03:19 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* "George M Ericson" <ericson at>
Just to be clear.  Your post is out of context for most of your readers.
You were asked to comment on two options for solving a problem with current
initiator side implementations.  The first proposal was to keep the
Semantics/Syntax of Task Set Full the same.

For that first proposal, I would recommend explicitly stating in the
definition of Task Set Full, that: For any initiator, the number of tasks
accepted before Task Set Full is returned must not be assumed to be a

And, without getting into details, this is an issue even for the
"share-nothing" model.


-----Original Message-----
From: owner-t10 at Symbios.COM [mailto:owner-t10 at Symbios.COM]On Behalf Of
Ralph O. Weber
Sent: Saturday, June 27, 1998 12:04 AM
To: -T10 Reflector
Cc: Houlder, Gerry; Ericson, George
Subject: RE: Mulit-Initiator Task Set (Queue) Full vs Busy responses.

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* "Ralph O. Weber" <ralphoweber at>
I am adamantly opposed to the proposed changes in the definition of
QUEUE FULL status.

The current SCSI definition of QUEUE FULL is correct.  It is correct
because it is open-ended, allowing a variety of implementations and
any enhancements to current implementations a future of invention
might hold.

The proposal to restrict the definition of QUEUE FULL to "you've hit
the fixed-for-all-time upper limit" is wrong.  It would constrain
current implementations in all the ways that Gerry Houlder has
described.  Worse still, it would prohibit an innovative company from
building a better SCSI device.

The fact that some system implementations are already constrained in
the same way that the proposed change is constrained cannot justify
the proposed change to the SCSI standards.

Firstly, the existence of even one system that is implemented
correctly (in a manner that fully utilizes the current SCSI
definition) is sufficient cause to maintain the current definition.
Since I am aware of at least one such system and suspect the existence
of a couple more, T10 is obligated to the SCSI community to make no
changes that break properly designed high-performance systems.

Secondly, the current implementations that assume QUEUE FULL sets a
fixed boundary are relying on other information to know that this
design decision is correct (or at least adequate), or the
implementations are flat-out wrong.  If the design is wrong and if
that mistake produces a noticeable adverse effect on the system
performance experienced by the system's user community, then the
developers of that system will find themselves encouraged to implement
proper support.

BTW As I understand it, the NT sharing model is share-nothing.  This
means that at any given instant, only one processing unit will be
performing I/O operations on any given disk.  This fundamental
clustering model assumption can justify a design decision to assume
that QUEUE FULL sets an upper bound on queued requests, if in fact
that is the NT assumption.

Because of the share-nothing model, the processor that gets QUEUE FULL
knows that no other processors are consuming device resources.  To a
first approximation, receipt of a QUEUE FULL does indicate that device
resources have been exhausted by the number of outstanding requests.
There are, of course, secondary effects that might cause the QUEUE
FULL boundary to move, even for a single processor.  However, a
reasonable person might find it justifiable for the NT developers to
choose to ignore such secondary effects in their initial cluster
software versions.

Symbios opposes the proposed restrictions on the definition of QUEUE



* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list