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

ROWEBER at acm.org ROWEBER at acm.org
Fri Feb 28 16:12:49 PST 1997

* From the SCSI Reflector (scsi at symbios.com), posted by:
* ROWEBER at acm.org
This note is an attempt to address the gaggle of, "What does Ralph/Symbios
want?", questions posed by Gerry Houlder.  Although I can make clear
statements about what Ralph wants, with regard to what Symbios wants I'm
must state that no certain answer exists.  I have discussed the matter with
some Symbios employees, but not nearly enough to be certain that I speak
for what Symbios wants.  In this regard, I'll cast an individual vote.
(Those unfamiliar with individual votes are encouraged to contact Gene

First and foremost, I want a standard that does not give its readers the
impression that something works, when in fact, it does not work at all. 
The current SPC text does this in the definition of QErr=1 behavior.
QErr=1 (or as proposed in 96-277r1, QErr=01) does not work in multi-
initiator systems.  Yet, the current SPC text unambiguously specifies that
it does work.  One of of the failure modes (but not the only failure mode)
is described in the document containing my proposal.  Laboratory experi-
ments has shown that one cannot even boot a second initiator on a bus
containing a disk set to QErr=1 behavior without encountering its broken
multi-initiator effects.

QErr=1 is broken for multi-initiator environments and SPC-2 must be changed
to correct this problem.

A side effect of the primary requirement is a secondary requirement that
the definition of Basic Queuing be amended.  If 96-198r4 (the approved
proposal defining Basic Queuing) is incorporated in the applicable SCSI
standards documents as written, the result will be standards that leave
their readers believing that Basic Queuing can be used in a multi-initiator
environment.  Because 96-198r4 requires the QErr=1 behavior, applying
96-198r4 to the SCSI standards without amendment is just as unacceptable 
as the current situation in SPC.  Claims about the single-initiator intent
behind of 96-198r4 notwithstanding, the voted on and approved document
contains no such wording, which means that no such wording will appear 
in any standards that are derived from 96-198r4.  96-198r4 is broken with
respect to multi-initiator environments (for which it implies it should
work) and the standards based on it will be similarly broken, unless the
technical editors apply a very heavy editing pen, probably a heavier
pen than X3T10 members would want.

I see two possible amendments that can be applied to 96-198r4.  One such
amendment is contained in my proposal, 96-277r1.  There are a few
variations on my proposed amendment, but with your indulgence, I will
postpone discussing the variations until later in this message.

The other possible amendment to 96-198r4 (not discussed in my proposal)
would be adding a requirement that Basic Queuing be functional only in
single-initiator environments.  Such an amendment would have to take the
form of a requirement that targets running under the Basic Queuing model
prohibit interactions with more than one initiator at a time.  The reason
that the burden for guaranteeing a single-initiator environment must be
placed on the target is as follows.

The very first interaction between a target and a new initiator is
establishment of a Unit Attention describing the last power up or bus reset
detected by the target.  The Unit Attention condition will result in
delivery of a CHECK CONDITION status to the new initiator.  The CHECK
CONDITION status invokes the broken QErr=1 behavior described in my
proposal.  It should be obvious that a newly booting initiator has no 
way to anticipate or correct these disastrous effects.  Also, the SCSI
standards must protect users from these effects, just as the standards
protect users from other disastrous effects of misconfiguring hardware.
This is the system integrity equivalent of requiring that connectors be
keyed so that they cannot be inserted upside-down.

The reason I have not proposed the single-initiator amendment is that I
seriously doubt that targets can be required to provided the necessary
guarantees.  Targets that require a login procedure surely can.  But,
classic SCSI parallel bus targets will find providing the guarantees
difficult, if not impossible.  I have a long laundry list of gotcha's
that can be employed in any working group debate that attempts to prove
that the guarantees can be provided, and I am confident that Ed Gardner has
an even longer list.  (We've both been there before.)  However, I'll not
bore y'all with that here.

Now, I return to the variations on the amendment that I have proposed for
96-198r4.  I have noted two variations.  One variation would eliminate the
requirement for only one QErr behavior under Basic Queuing.  I accept the
argument that such a change would violate the spirit of Basic Queuing
and recognize the potential for cost savings resulting from an implemen-
tation with no options.

The other variation would establish QErr=00 as the required behavior.  It
should surprise no one to find that Symbios agrees with the other systems
houses regarding this variation.  QErr=00 is the preferred operating mode
for disk drives in Symbios RAID controllers.  However (like the other
systems houses), Symbios will defer to the disk manufacturers if their
preference is QErr=11 for Basic Queuing.

The only other "what does Symbios want" questions I can find to answer fit
the general "motherhood and apple pie" model.  Of course Symbios wants the
most cost effective disks that meet our functional ability and performance
requirements (and Symbios requires multi-initiator functional drives).
Symbios has believed those who told us that we would gain something in this
regard as a result of our supporting the Basic Queuing proposal.  Without a
doubt, we are disappointed to be told that we've been sold a bill of goods
and that all drives will be Full Queuing, unnecessarily expensive drives,
regardless of what happens as a result of this debate.

I fully concur with Ed Gardner's argument about the task management
function requirements in 96-198r4.  Specifically, I am skeptical about an
argument that says I'll be paying more for QErr=11 drive microcode when the
96-198r4 task management requirements demand that the needed microcode be
present in every drive anyway.

I think I've run out of questions to answer.

* 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