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

[Matt Wakeley <matt_wakeley@agilent.com>]

Doug, re-read my message.  I did not say anything about disconnecting as a
means of recovery.

-Matt

Douglas Otis wrote:
> 
> 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
> >