Command queueing: an alternate approach

robbyb at robbyb at
Wed Jul 26 08:11:23 PDT 2000

* From the T10 Reflector (t10 at, posted by:
* robbyb at

I propose going to stateless commands and bypassing this whole mess.  I'll
have a proposal soon.

I thought I would lay out my general line of thinking.  The proposal is not
truly stateless, but the states are explicit.  It's really the implicit
nature of the states that causes all the problems.  The reason I did this
instead of going truly stateless was for application compatibility.
1. Read and Write commands would get a logical block number in them.
2. System would be required to use a locate file/block command as opposed
to space for queued operation.  It would only be required if such commands
were queued.  Given the relative infrequency of these types of commands,
Space commands could be continued so long as they aren't queued with very
small performance impact.
3. I want to do this in such a way that the work can be done in the device
drivers, so that there is NO CHANGE to application code.
4. Obviously, drivers can take advantage of the benefits of these stateless
commands even if no command queueing is being done.

Relative to all the other issues in command queuing this is a small effort
with a big payoff.  I think you've worked with the tape group enough in the
last couple of years to appreciate the strains and problems maintaining
data integrity that the current tape drive command set imposes on the
entire system, top to bottom.

Robert Snively <rsnively at Brocade.COM> on 07/19/2000 12:51:51 PM

Sent by:  owner-t10 at

To:   t10 at, fc at
Subject:  Please review: Preliminary discussion of CRN approaches

* From the T10 Reflector (t10 at, posted by:
* Robert Snively <rsnively at Brocade.COM>

Well, some of the information is in.  I am not counting votes yet (we will
do that at the FCP-2 meeting in Seattle), but I am filling out benefits
of each approach.  I am attributing these views as best I can. Note that
the rigorous ordering of awaiting command complete status is the presently
accepted mechanism for managing ordering, so that present day drivers
do not require either type of CRN.  All of these discussions reference
implementations (or in some cases, implementations in late stages of

Please review these, fill in the holes, and get your views on the reflector

A)  Considerations on using CRN per target

    1)  Overview

     The implicit assumption is that by assuring the ordering of each
     command operation on an I_T nexus, the delivery to the logical unit
     will necessarily be correctly ordered.  To do this, a CRN on an
     I_T nexus basis would be appropriate. (Wakeley, 7/11)

    2)  Benefits of using CRN per target

     a)  Driver independence

          At present, there are no drivers that have any knowledge of
          CRN functionality.  Using CRN on an I_T nexus basis would
          allow the HBA to enforce ordering at a low level, without
          the awareness of the driver and without the requirement to
          rewrite the higher drivers for FC CRN use. (Wakeley, 7/11)

     b)  Interface independence

          At present, all the drivers for other interfaces do not create
          an explicit indication of ordering for commands.  Since there
          is no architectural support for CRN in any of the other
          SCSI technologies, it is unlikely that FC CRN drivers will be
          created except for very special cases.  (Wakeley, 7/11)

    3)  Problems of using CRN per target

     a)  Stalling of unaffected logical units

          A failing or missing command for one logical unit stalls
          all logical units, even those doing unrelated tasks
          managed by a different driver, until the failing one
          is recovered. (Snively, 7/18)

     b)  Error recovery bypass of ordering

          The error recovery driver must selectively disable CRNs
          (I assume by posting a 0 value) to sneak stuff by the blockade
          to complete the recovery for a logical unit. (Snively, 7/18)

     c)  Task management an exception for the I_T nexus

          Task management must still be outside the CRN structure in order
          to perform some of the recovery mechanisms.  (Snively, 7/18)

     d)  Requirement to support both ordered and non-ordered on same target

          Bridge devices attach disk drives (no ordering requirements) and
          tape drives (ordering requirements) behind a single target.
          them to both support target oriented CRNs is inappropriate.
          (Baldwin, 7/18)

          Note that this may be addressable by using the task ordering
          attributes to automatically include or exclude individual
          commands from the ordering process (Snively, 7/19)

     e)  No protection for ordering problems outside the FC fabric.

          Some queue structures historically used in HBAs and in
          targets do not enforce ordering.  The result is that the
          application's ordering requirements may be subverted by either
          the driver to HBA queuing or by the target to logical unit
          queuing.  Note that more modern implementations may have
          cured all cases of this. (Snively, 7/19)

B)  Considerations on using CRN per LUN

    1)  Overview

     The explicit assumption is that any application that cares about
     ordering will provide ordering information that will be transported to
     only natural destination of an application request, the logical unit.
     Logical units or operations that do not require such rigorous
     verification of ordering will operate with the loose ordering
     presently assumed for FC fabrics. (FCP-2r4)

    2)  Benefits of using CRN per LUN

     a)  Explicit low-level management of ordering

          Ordering can be applied as required for those logical units that
          require it. (FCP-2r4, Baldwin 7/18)

     b)  Ordering protected across queue boundaries

          The desired ordering of commands from an application to a
          logical unit is preserved independent of queuing issues
          associated with application to driver queues, driver to
          HBA queues, fabric re-ordering, and target to logical unit
          (Snively 7/19)

    3)  Problems of using CRN per LUN

     a)  No drivers are available to pass CRN through to a logical unit.

     b)  Drivers will require FC specific capabilities to use CRN anyway.
          (Baldwin 7/18)

Bob Snively
Brocade Communications           Phone  408 487 8135
1901 Guadalupe Parkway
San Jose, CA 95131               Email   rsnively at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list