RE: Avoiding deadlock in iSCSI

[julian_satran@il.ibm.com]

Where would you suggest it should be done without violating layering
constraints?

Julo

Peter Johansson <PJohansson@ACM.org> on 12/09/2000 19:29:15

Please respond to Peter Johansson <PJohansson@ACM.org>

To:   IP Storage <IPS@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: Avoiding deadlock in iSCSI




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