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-
}>initiator systems. 
} 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 
multi-initiator systems.


* 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