Fw: 96-277r1 - Proposed Change in QErr for SPC-2

Bob Snively Bob.Snively at Eng.Sun.COM
Thu Feb 27 09:18:19 PST 1997

* From the SCSI Reflector (scsi at symbios.com), posted by:
* Bob.Snively at Eng.Sun.COM (Bob Snively)

That is intriguing, because I felt that QErr = 00 (which treats each
command and its errors as independent events, not affecting either
those commands that have already been executed, nor those commands
yet to be executed) is by far the simplest, broadest, and most
appropriate model.  Every command is required to respond to software with a
GOOD status, a failure status, or to be caught by a timeout, independently.

This is especially effective in P1394 and FCP implementations that
have the capability of automatically providing sense information
and clearing ACA.

This places the responsibility for completion of a series of commands
directly on the software, without any possible reflection on the
differing capabilities of drives and the varying definitions of
event queueing.  Software instances that are cooperating in a read-only mode
need not concern themselves with locking or other details.  The only
question is whether the requested information came back.

Software instances that are not cooperating must complete a successful
Persistent Reservation before beginning sequences that are subject to
being fouled up by other software actions.

Software instances that are cooperating can protect and share their
data with appropriate locks and configuration management.

Sequences of instructions that require ordered behavior can be
executed explicitly in order, not starting a second command until a
first command is reported as complete.  Note that lies about completion
are already common among SCSI devices for performance reasons, and
for most device types, would still be appropriate depending on the
subsystem architecture and the availability of non-volatile semiconductor

For those reasons, the capability of operating with QErr = 00 must
be mandatory.  I personally don't care about any of the other QErr
states and would try to encourage people to avoid their use. 
I don't mind if they are implemented for special purposes, as long as
no increase in drive cost results. I sure
hope that SBP-2 has no architectural requirement for QErr > 0 behavior.
If it does, that is an oversight that should be corrected.


>From PJohansson at aol.com Wed Feb 26 22:15:41 1997
>Date: Thu, 27 Feb 1997 01:08:50 -0500 (EST)
>* From the SCSI Reflector (scsi at symbios.com), posted by:
>* PJohansson at aol.com
>In a message dated 97-02-26 23:03:30 EST, gardner at acm.org (Edward A. Gardner)
><<Given recent reflector traffic, today I would vote for QErr=00 being
>mandatory, with support for other QErr values being optional.  Doing nothing
>has to be simpler than aborting any or all commands (after all, it's the same
>action as when a command completes normally).  Single host systems can always
>issue a TARGET RESET.  And it seems to be the preference of multi-host
>I've extracted only this portion because I agree with the rest of what Ed has
>This one paragraph stands in opposition, though. If I understand such things
>correctly, QErr == 00b mandatory would REQUIRE that Basic queuing targets
>permit initiators to set QErr to this value. This is not OK. SBP-2 was
>designed to support and implement the Basic queuing model. SBP-2 devices
>can't, don't or won't (pick your favorite verb) QErr == 00b. Basic queuing
>was also intended to restrict optionality.
>I am still in support of QErr == 01b (only the faulted initiator's task set
>is aborted) as a mandatory requirement for Basic queuing.
>Incidentally, Ed, a very sincere "THANKS!" for doing all that research into
>our archives.
>Peter Johansson

* 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