Fw: 96-277r1 - Proposed Change in QErr for SPC-2
Gerry_Houlder at notes.seagate.com
Thu Feb 27 11:19:56 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
I agree that Ed's recap of the written record is useful. However, I have
recollections of things that weren't written that have influenced this
proposal. These things have been forgotten
(1) Jim McGrath (the one from Quantum) originally proposed basic queuing. His
original proposal was outlined on an overhead in front of the working group and
there was about a half hour of discussion in which Jim didn't get much support
for the idea. After the Working Group was adjourned, Jim conducted an in depth
discussion (another hour or more) of what he wanted and why. This was a small
group (5-8 people) and anyone that attended had no doubt that the proposal was
intended for single initiator systems and "legacy" applications.
There was considerable discussion about clearing queued commands. The QERR=1
response of "clearing all commands" was deemed critical to the "simplified"
(meaning substantially less drive firmware) proposal. He also wanted to have
ABORT required instead of CLEAR QUEUE because it is used in legacy driver
software. The ABORT message has a heritage going all the way back to systems
without arbitration or with only single bit selection (clearly single initiator
systems). CLEAR QUEUE is a more recent addition to SCSI and is less used by
driver software. The fact that the drive was actually going to do a CLEAR QUEUE
in response to this message was deemed unimportant because "the result is the
same for single initiator systems anyway".
(2) Pete Dougherty became champion and author of the official proposal. I
presume this was because Jim knew he would not be attending the next few X3T10
meetings and was happy to find a champion that was going to attend.
Pete started with 3 levels of queuing support, which was trimmed to two levels
by popular acclamation. Pete removed the single initiator restriction/
recommendation because he felt (as do others) that the flush all commands in
multi-initiator system is a manageable problem. He felt strongly about it and
the rest of us went along with his opinion. After all, it was his proposal.
What all of us forgot about was the nuance of CLEAR TASK SET operation versus
ABORT TASK SET operation. This nuance becomes a significant difference when
basic queuing is applied to multi-initiator systems. I think it was ignored
because a lot of people (including me) remembered Jim's emphatic arguments
about basic queuing applying to single initiator systems even though that
wording was no longer in Pete's proposal.
(3) That brings us to today. Ralph's proposal is a great fix for using the
"clear other commands on CHECK CONDITION" feature in a multi-initiator system.
If a multi-initiator system really wants to do this, OK. I support Ralph's
proposal on that basis.
I want to see a clearer statement from Ralph (i.e., Symbios) on what he
expects to gain from this. Will a drive that supports this desired
configuration be cheaper than a drive that does full queuing and QERR=0? It
will not be. The new basic queuing definition is not available on any drive
today. A drive implementing this definition will be a "full queuing" capable
drive that has a few more lines of code to do the new QERR=11 function. This
will not be cheaper or more reliable than using an existing "full queuing"
drive with QERR=0.
If Ralph really wants the "clear other commands on CHECK CONDITION" feature in
a multi-initiator system and he doesn't care if the drive cost the same as
current full featured drives and won't be available for several more months,
then accepting the proposal will give him what he wants.
Also note that, if we accept this proposal, Jim's cheaper "simple queuing"
drive (with the functionality outlined in item (1) above) will not be usable by
Ralph. This is problem 1. Can Symbios live with this?
Jim will not have a description of his "simple queuing" drive in SAM like he
wanted. This is problem 2. The "basic queuing" description will have evolved
into something with much more firmware complexity than what he wanted. Jim
might be willing to live with this. I recall early statements from him that he
wanted a description of "simple queuing" in the standard, but he would produce
it as a de facto standard product if he had to. I think we will hear more about
this from Jim.
Speaking for Seagate, I don't know of any implementation planned that matches
Jim's simple queuing. All of our SCSI products support the full queuing
functionality, even the cheaper "XL" drives that do have reduced features. My
company doesn't have much of a stake in the outcome of this debate, but the
whole basic queuing concept seems to be causing MORE fragmentation and
complexity instead of less.
Our industry would be better off if we all decided that full queuing is
mandatory, only the ACA tag stuff and supporting more than one value for the
QERR field is optional, instead of trying to draw a line and say that a lower
functionality is also valid. There seem to be too many different places to draw
lines. Too many options in this area can lead to reduced reliability!
I hope Symbios is being very careful about what they are asking for, because
they probably will get it.
* 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