Re: Avoiding deadlock in iSCSI

["Matt Wakeley" <matt_wakeley@agilent.com>]

I just keep hearing more and more reasons for having separate control and data
TCP connections (read: a minimum of TWO).  That way, if the command queue in
the target fills up,  no big deal, it simply stops reading from the command TCP
stream and lets TCP do its window management.  Mean while, the data TCP
connection is still free and clear to transfer the data for the commands
accepted.

-Matt Wakeley
Agilent Technologies

Peter Johansson wrote:

> 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