Re: VI (Was: Avoiding deadlock in iSCSI)

[Stephen Bailey <steph@cs.uchicago.edu>]

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

If by connection in FCP, you mean login, you actually have a choice.
If an initiator choses to recover the session and does it within the
defined time, it may do so.  Early in FCP, none of the recovery
mechanisms worked correctly, so doing this triggered all sorts of
horrible bugs.  The alternative is just to log in from scratch, which
has the effect of killing the session and allowing the target to
recover its state without waiting for the timer to expire.

The problem with iSCSI seems to be the long maximum recovery timer
value.  Obviously, the amount of unrecovered state (including orphan
operations) increases proportionally.  Whether that's a big deal or
not seems to depend upon many implementation factors.

In FCP if an initator dies and is reborn, when it reconnects, the
orphan session state is automatically recovered by merit of the fact
that there can be only one session between two endpoints.  In iSCSI,
there can be multiple sessions between endpoints (sure, it's strongly
discouraged, but it would be boneheaded to prohibit it), so starting a
new session can not recover state from an old one.

One could argue that an iSCSI connection is much more durable than an
FCP login, and when it fails, immediate recovery is unlikely anyway.
Would reservations be a problem in this approach?  If you think so,
I'd be grateful for you (or somebody else) to go ahead and make that
argument.  The reason I say this is that reservations seem to have
problems at a SAM level which are independent of transport, and I'm
not sure this behavior would make them any worse.

Steph