96-274r0 -- Proposed Change in QErr=1 Behavior for SPC-2
ROWEBER at acm.org
ROWEBER at acm.org
Mon Nov 25 14:13:52 PST 1996
* From the SCSI Reflector (scsi at symbios.com), posted by:
* ROWEBER at acm.org
Firstly, I apologize for letter bombing the reflector and then leaving town.
By way of explanation, I believed that there was time pressure to complete
preparation and deliver of the proposal. But, having succeeded at meeting
the publication goal, I then needed to attend to other job goals.
While I appreciate Charles' offer to take the blame, you all should continue
to toss the stones in my direction. You're going to get to toss stones at
the January Working Group meeting. So, why not engage in a little "pre-
I will now attempt to address some of the issues raised during my absence.
Those folks who have attempted to guess my motives for making the proposal
have gravely misjudged me. While I certainly have a host-software past and
might reasonably be expected to make proposals with software advantages in
mind, such is not the case here.
There is a serious protocol instability in the case where QErr=1 is combined
with a multi-initiator environment. The original proposal presents one
example of the instability and Charles Binford has offered a second example
in a recent message to the reflector. Other people who have examined the
problem description have offered comments such as, "Yep, the standard is
As I see it, I'm doing something equivalent to telling the committee that
the bus is unstable, unless it is terminated. In this case, unlike issues
of termination, the committee probably has many options for resolving the
protocol standardization failure. I proposed a solution because past
experience shows that the committee is more likely to act on a proposal
containing a solution than on a complaint that lacks the specificity of
a proposed change.
I am, by no means, wedded to the specific solution contained in the r0
proposal. (Nobody in their right mind would expect to get an r0 proposal
past this crowd.) However, I am disappointed by the absence of counter
proposals. It's so atypical of the X3T10 membership to pretend that if
nobody sees a problem then it will just go away.
"The fact is that the QErr feature was designed for single
initiator systems and multi-initiator systems were supposed
to use the ACA ACTIVE technique (or at least ..."
If QErr=1 was intended for use only by single initiator systems, then why does
the standard describe in excruciating detail how the device server shall behave
with respect to multiple initiators? If the problems in multi-initiator
environments were known from the outset, why were they swept under the rug?
(Oops, strike that 'when did you stop beating your wife' question.) But
regardless of the past, the problems are known clearly now and they demand
action. It is, at best, unfair to the readers of the standard to imply that
QErr=1 will work in a multi-initiator environment without some type of
extraordinary effort on the part of the application clients.
In defense of the r0 proposal, I offer the following points:
1) The behavior experienced in single initiator environments is
not changed. This covers the majority of the cases.
2) The behavior in multi-initiator environments is fully stabilized.
None of the problems described thus far will occur in systems
where the proposal is adopted.
3) The proposal requires no functions that are not already present
in devices that implement the Basic queuing model. The ABORT
TASK SET task management function is required for devices that
implement the Basic queuing model. The proposal requires a
behavior that is essentially the same a an ABORT TASK SET,
whenever a CHECK CONDITION status is sent to the application
client. (This analysis is based on a review of 96-198r3.
It assumes that the table on the first page of that proposal
was not changed in 96-198r4, which comes from my recollection
of actions taken at the November SCSI Working Group meeting.)
Yes, the proposal requires a change in the behavior of QErr=1 in a
multi-initiator environment. Since the currently specified behavior
is dysfunctional, a change (some kind of change) is required.
Ralph O. Weber E-Mail: ralph.weber at symbios.com
Symbios Logic Inc. Voice: 214-733-3594
17304 Preston Road Fax: 214-713-8121
Suite 635 SCSI BBS: 719-533-7950 300--14400
Dallas, TX 75252 baud
* 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