RE: iSCSI: Out Of Sequence due to null sequence with multipleconnections.

[Douglas Otis <dotis@sanlight.net>]

Matt,

If the sequencer gets stuck due to some target resource limitation, you are
now sitting behind a queue that you have no control over.  If you use the
immediate command as a bypass to this problem, its placement with respect to
pending commands is unknown.  Tearing down the entire session does not
resolve the state of the target with an ambiguity of the delivery from the
sequencer to the target still unresolved as well as commands in progress.
If the goal is to be sure of the state of the target, severing the session
does not accomplish this.  Assigning a sequence to an immediate command with
those pending at the sequencer to be rejected is a simple control to have in
place that will likely provide the needed actions to resolve a problem.
Disconnecting simply leaves the target state unknown permanently while
hoping the target is not sensitive to replaying commands.

Doug

> In simple terms, what Doug is asking for in (B) is an "immediate"
> command that
> will go and abort all pending commands in the iSCSI queue that
> have not yet
> been delivered to the SCSI layer due to missing commands sequence numbers.
>
> I'm wondering how useful this is.  The initiator could simply look at the
> ExpCmdSN from the target and resend the missing command(s) if the target
> appears to be "stuck".  Given the way TCP works, the only time the target
> could get "stuck" is if a TCP connection fails.  In which case
> the connection
> would be re-established and the missing commands resent.
>
> -Matt
>