RE: Avoiding deadlock in iSCSI

[Peter Johansson <PJohansson@ACM.org>]

At 07:25 AM 9/12/00, Stephen Byan wrote:

>I think this is a T10 bug, and iSCSI should defer to T10 to fix it.

The "this" Stephen refers to, summarized below, is not a T10 bug.

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

The malfunction is a property of the interaction of the transport protocol 
(T10 terminology) with SAM. In the case of iSCSI, it has to be designed so 
that no new commands can be accepted after the QUEUE FULL condition until 
the target has confirmed knowledge that the initiator is aware of the 
error. That is, the ordered pipeline of commands between the two endpoints 
must be resynchronized before work may resume.






Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson@ACM.org