Command queueing: an alternate approach
robbyb at us.ibm.com
robbyb at us.ibm.com
Wed Jul 26 08:11:23 PDT 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* robbyb at us.ibm.com
*
Bob,
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.
Regards,
Rob
Robert Snively <rsnively at Brocade.COM>@t10.org on 07/19/2000 12:51:51 PM
Sent by: owner-t10 at t10.org
To: t10 at t10.org, fc at network.com
cc:
Subject: Please review: Preliminary discussion of CRN approaches
* From the T10 Reflector (t10 at t10.org), 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
future
implementations (or in some cases, implementations in late stages of
development).
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.
Forcing
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
enforcing
ordering will provide ordering information that will be transported to
the
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
queues.
(Snively 7/19)
3) Problems of using CRN per LUN
a) No drivers are available to pass CRN through to a logical unit.
(general)
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 brocade.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list