96-277r1 - Proposed Change in QErr for SPC-2
ROWEBER at acm.org
ROWEBER at acm.org
Tue Mar 4 07:53:13 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* ROWEBER at acm.org
}>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-
} As far as I know this is an erroneous assertion. I think we will need to talk
}it through in the working group. The definition was insisted upon by one of the
}earliest implementors of multi-initiator SCSI systems. I have the impression
}that Ralph's discussion is from the perspective of SCSI only communication
}between the initiators and/or from the perspective of non-cooperating
}initiators. The behavior I think was to take the place of ECA and to stop
}continued operation until the serious error software resources could be
The reference to ECA (Extended Contingent Allegiance) in this comment leads
me to believe that the QErr=0 (retain all queued operations) is being confused
with the QErr=1 (abort all requests and establish a Unit Attention condition
for other initiators) behavior. I have no quarrels with QErr=0 behavior,
which, of the two choices, more closely resembles ECA. As noted previously,
Symbios and several of the other systems houses prefer QErr=0 behavior.
However, if the claim is that QErr=1 behavior is appropriate for multi-
initiator environments composed of cooperating initiators, then my assertion
that QErr=1 is broken in such circumstances is not erroneous. Let's assume
for a moment that cooperating initiators exchange messages on some other
communications medium (e.g., Ethernet) and that such messages are used to
modify driver behavior in ways that manage SCSI bus transactions for minimal
disruption. Based on tests conducted by Symbios, one such message would
have to be:
"Standby for system boot"
"I'm booting from your SCSI device with QErr=1. This will cause a
Unit Attention condition for me, with the resulting CHECK CONDITION
status causing all your pending requests to be aborted. Cleanup your
pending requests and begin testing for the Unit Attention condition
that will be established for you when your pending requests are aborted."
Personally, I cannot imagine an operating system that is capable of sending
such a message before it's even booted. Clearly, the problem is as bad or
worse for non-cooperating initiators. Yet, SPC strongly implies that QErr=1
will work in a multi-initiator environment, by carefully defining the work
that must be performed by device servers in such instances. From a software
implementor's point of view, such an implication is as bad as saying that
terminators are optional.
} Systems that are not benefited by QErr=1 and more importantly are disrupted by
}the behavior (assuming they have not succumbed to the original error) simply
}should not set QErr=1. After all if it hurts, stop doing it.
The problems with QErr=1 in multi-initiator environments are substantial
enough to deserve some type of warning information in SPC. Such a warning
is part of the new SPC-2 text contained in my proposal.
Beyond that, there is a problem with the definition of Basic Queuing.
By choosing QErr=1 as the only permitted implementation for Basic Queuing,
X3T10 has effectively prohibited the use of Basic Queuing devices in multi-
initiator environments. If this is truly the intention of the committee,
then the severity of the problems with QErr=1 obligate the committee to
prohibit such usage (as described in my last message). On the other hand,
I and several colleagues at Symbios are hoping that the committee will decide
that it is unacceptable to have Basic Queuing be so hopelessly useless in
* 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