RE: VI (Was: Avoiding deadlock in iSCSI)

[julian_satran@il.ibm.com]

Charles,

No. As long as you can  reestablish at least one TCP connection
you should be fine. Security context must also be maintained.
However it is still an open issue what to do SCSI wise.
What I assumed is that target will do nothing and initiator will
do a target management function (some form of abort I assume).

Julo

Charles Monia <cmonia@NishanSystems.com> on 27/09/2000 22:15:57

Please respond to Charles Monia <cmonia@NishanSystems.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: VI (Was: Avoiding deadlock in iSCSI)






> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Wednesday, September 27, 2000 12:05 AM
> To: ips@ece.cmu.edu
> Subject: RE: VI (Was: Avoiding deadlock in iSCSI)
>
>
>
>
> Charles,
>
> This goes to the hearth of problem.
> To avoid this effect we propose (like FCP) unordered messages
> to go always
> through -
> allow the initiator to decide which task management messages he deems
> "urgent".
> But if you have a single connection and the TCP window is
> closed you are
> left with only
> one think to do - drop the connection (and that is exactly what FCP is
> doing for similar
> reasons!).
>
> Julo
>

Hi Julo:

Does dropping the connection blow away the iSCSI session? If so, FCP does
nothing like that.

In FCP terms, only the command is discarded.  The "session" established at
FC login time remains intact.  That is, other pending commands and
initiator-specific device context (mode page settings, reservations and the
like) are unaffected.

Charles