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

["Douglas Otis" <dotis@sanlight.net>]

David,

I agree. Just using a flag rather than a zero CmdSN for immediate delivery
is a substantial improvement and this could be the extent of the change.
Without the sequencer reject, it does require interlocked target behavior
thus forcing the SCSI layer and the target to ensure a deterministic
recovery.  I tend to be conservative on how errors are handled.  To argue
rarity, ensuring a certain result is helpful following these types of errors
with the additional benefit of not needing timeouts for hole filling.  The
downside is there will be a potential list of rejected commands from
innocent LUNs to retry if the problem is LUN related.  I'll prefer a list
over a series of timeouts flushing a connection sputter that may result in a
series of sequence holes.

A close of a failing connection should also reject commands being held in
the sequencer with allegiance to the now closed connection.  As in this
case, reject does not have allegiance but the retry methods should look the
same.  In other words, nothing is being added to what is already in place
for a low code impact change category.

As a side note, if you were attempting an urgent shutdown, you may wish to
send more than one such immediate command rather than waiting for a response
from each LUN before sending the next.  As such, flow control and
acknowledgement for this activity becomes desired.

Doug

> > The only concern with that solution is that it may delete
> > a whole lot of unrelated SCSI I/O tasks as the sequencer cmdSN
> > moves way up to the cmdSN of the task_mgmt command.  "Abort task"
> > as such will not exist in the iSCSI world.   These unrelated
> > commands will now have to be retried by the initiator.
>
> FWIW, that's not a necessary consequence of the proposal to use
> a flag instead of a zero CmdSN, although it does appear to be the
> way that Doug envisions implementing this.
>
> --David
>