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

Larry Chen larryc at maxstrat.com
Wed Feb 26 20:21:11 PST 1997


* From the SCSI Reflector (scsi at symbios.com), posted by:
* Larry Chen <larryc at maxstrat.com>
*
Ed,
Thanks for the summary.

I have two cents to offer from a systems perspective.

Are the server system folks planning on supporting both Basic and 
Full Queuing? I hope this is NOT the case.

If one queuing scheme can NOT be agreed to by everyone for all 
applications, then I would favor Jim's approach. Let the desktop
folks use Basic Queuing and the server folks use Full Queuing.

Let the limitations of Basic Queuing be known to all and let
the markets decide what queuing scheme is used.

Larry
On Wed, 26 Feb 1997 20:32:14 -0700  Edward A. Gardner wrote:
>* From the SCSI Reflector (scsi at symbios.com), posted by:
>* "Edward A. Gardner" <gardner at acm.org>
>*
>The discussion of what Basic Queuing is or was supposed to be has gotten
>intensive enough that it's worth going back and reviewing what we've
>actually agreed to.  The relevant document is 96-198r4, which was approved
>or accepted at the November working group and plenary meetings in Palm
>Springs.
>
>Reviewing this document and its antecedents, the first thing that stands
>out is that nowhere is there a statement that this is intended for or
>motivated by single host systems.  The purpose stated in all revisions of
>the proposal (those distributed in mailings) is:
>
>    The essence of the proposal is to modify SAM-2 to permit two levels of
>    task management complexity: basic and full.
>
>This purpose is every bit as valid, if not more so, for multi-host systems
>as for single host systems.
>
>The next thing that stands out is that the ABORT TASK, ABORT TASK SET, and
>TARGET RESET task management functions are singled out as being mandatory
>for a Basic Queuing device.  The CLEAR TASK SET function is explicitly
>identified as being optional.  This is significant because implicitly
>aborting commands after an error amounts an implicit task management
>function.
>
>Ralph Weber and Peter Johansson advocate that targets perform an implicit
>ABORT TASK SET when an error occurs, only aborting tasks from the same
>initiator (QErr=11 in Ralph's proposal).  Jim McGrath objects to this,
>instead arguing for an implicit CLEAR TASK SET, aborting all tasks from all
>initiators (QErr=01 in Ralph's proposal).  The conclusion is clear, Ralph
>and Peter are asking to reuse a function that must already exist in the
>target drive, while Jim is asking for a optional function that need not
>otherwise be implemented.  Given the Basic Queuing proposal as it was
>approved by T10, Ralph's proposal is unquestionably simpler.
>
>Incidentally, this is/was not a new or changed feature of Basic Queuing. 
>ABORT TASK SET is listed as mandatory and CLEAR TASK SET as optional in
>every version of the Basic Queuing proposal that has been distributed in
>the mailings, specifically:
>
>96-198r1    dated July 18, 1996
>96-198r3    dated September 18, 1996
>96-198r4    dated November 7, 1996
>
>My memory (which I haven't verified against minutes) is that the question
>of ABORT TASK SET versus CLEAR TASK SET being mandatory was extensively
>discussed and decided the first time this proposal was discussed, at the
>July meeting prior to r1.  If there is something wrong with this proposal,
>there has been ample time to object.
>
>The final thing that stands out is the voting record from the November
>working group minutes, specifically:
>
>>> The group argued over whether to allow the QErr bit to be zero in
>>> the control mode page and failed to reach broad consensus on the matter.
>...
>>> The motion passed 17:2.  George Penokie and Jeff  Williams stated their
>no
>>> votes as being based on objections to the requirements placed on the
>>> control mode page.
>
>The working group "failed to reach broad consensus", my memory is that
>there was considerable dissension on whether to require QErr=1.  The two
>people who voted against the proposal gave this as their reason.  Speaking
>for myself, I understood the major issue to be that of solely supporting
>the Simple queue tag, the QErr value being a minor issue that could be
>fixed later, and felt it more important to establish Basic Queuing as a
>valid concept than to worry about a specific QErr value.  I believe I
>remember other people saying similar things, but there is no sufficiently
>detailed written record.
>
>Given recent reflector traffic, today I would vote for QErr=00 being
>mandatory, with support for other QErr values being optional.  Doing
>nothing has to be simpler than aborting any or all commands (after all,
>it's the same action as when a command completes normally).  Single host
>systems can always issue a TARGET RESET.  And it seems to be the preference
>of multi-host systems.
>
>Finally, I feel I must point out that, according to the minutes, neither
>Jim McGrath nor anyone else from Quantum attended the November meetings
>where this was approved.  For that matter, Jim attended neither the July
>working group (where a formal Basic Queuing proposal was first discussed)
>not the September working group.  He has not been present at any of the
>working groups that have dealt with this.  I would have more sympathy for
>Jim's arguments if he presented them in advance, rather than pretending to
>a revisionist history after the fact.
>
>Edward A. Gardner               gardner at acm.org
>Ophidian Designs                719 593-8866 voice
>1262 Hofstead Terrace           719 593-8989 fax
>Colorado Springs, CO  80907
>*
>* For SCSI Reflector information, send a message with
>* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
>

-------------------------------------------------------
Larry Chen             Tel: 408.383.1600 (x116)
MAXSTRAT Corporation   Fax: 408.383.1616
801 Buckeye Court      E-mail: larryc at maxstrat.com
Milpitas, CA 95035     URL: http://www.maxstrat.com/
-------------------------------------------------------



*
* 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