RE: iSCSI: Out Of Sequence due to null sequence withmultipleconnections.

[Douglas Otis <dotis@sanlight.net>]

Matt,

"There will never be a time where the immediate command will be used to
reach around the sequencer and the only reason a sequencer could be stuck is
due to a hole that can be discovered and eventually filled" if I understand
your statement.

There are also resource limitations between the sequencer and the target
that may lead to a stall or a long term delay that needs to be halted.  As
the sequencer has exhausted these resources, it waits and waits.  If there
is a tag left open for the 'get me out of this' command, the sequencer needs
some means to understand when to employ this trump card.  An immediate
command seems like a good means of creating such a signal. The problem is
what is the final state of this action and is the reason for maintaining
sequence on all commands sent to the target.  Sorry, but I looked to the
next possible action and tried to answer that as well.  I tend to be long
winded I guess as well as long in the tooth.

Doug

> 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
> > >
>