RE: Avoiding deadlock in iSCSI

[Stephen Byan <Stephen.Byan@quantum.com>]

Costa [mailto:csapuntz@cisco.com] wrote:

> I believe there is problem with the current SCSI behavior. 
> Consider the
> following scenario for a host with a pathological queue of 1
> 
> 
> 	1) Initiator sends command 1 (ORDERED attribute)
> 	2) Initiator sends command 2 (ORDERED attribute)
> 	3) Initiator sends command 3 (ORDERED attributge)
> 	4) Target reads command 1
> 	5) Target reads command 2
> 	6) Target returns queue full for command 2
> 	7) Command 1 completes
> 	8) Target reads command 3
> 	9) Target executes command 3
> 
> We have just violated the ordering constraints of the application by
> doing command 3 before command 2.

I think this is a T10 bug, and iSCSI should defer to T10 to fix it. From the
proposed charter (David, is there an approved charter yet?):

"The WG cannot assume that any changes it desires will be made in these
standards,
and hence will pursue approaches that do not depend on such changes unless
they are unavoidable and in that case will create a document to be forwarded
to the standards group responsible for the technology explaining the
issue and requesting the desired changes be considered. "

In practice, this bug doesn't bite very often because the only devices that
commonly implement command queuing are disks, and since most disk commands
are stateless, they are not sent as ordered commands.

This bug does present a problem for stateful devices such as tapes or
communication controllers. To accomodate WAN connections to those devices,
one might like to enable command-queuing, to pipeline around the
communication latency incurred in turning around from completion status of
the previous command to initating the next command. This bug makes it
impractical to implement command-queuing on stateful devices.

I suggest that it is T10 which needs to fix this bug, not the iSCSI
transport. For purposes of developing the iSCSI transport, I suggest we
ignore the bug, and assume the target will respond with TASK SET FULL or
BUSY, as appropriate. We should additionally document the problem and
forward it to T10 with a request to resolve the bug in SAM-2.

A possible fix might be to add a mode page bit that would require the target
to establish ACA on TASK SET FULL.

Regards,
-Steve

Steve Byan
<stephen.byan@quantum.com>
Design Engineer
MS 1-3/E23
333 South Street
Shrewsbury, MA 01545
(508)770-3414
fax: (508)770-2604