Subject: RE: iSCSI: Out Of Sequence due to null sequence with multiple co nnections.

From: [email-masked]
Date: Fri, 6 Apr 2001 20:17:46 -0400

> 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

> -----Original Message-----
> From:	Sandeep Joshi [SMTP:[email-masked]]
> Sent:	Friday, April 06, 2001 6:29 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: iSCSI: Out Of Sequence due to null sequence with
> multiple  connections.
> 
> [email-masked] wrote:
> > 
> > Sandeep,
> > 
> > > Still wading thru related emails but I believe that if a refCmdSN
> > > is added to the task management PDU (not present currently but
> > > could be added for task-related management commands), then it
> > > might fix the above-mentioned flaws and allow for safe execution
> > > and immediate delivery of the abort task to the target.
> > 
> > I think this is a functional subset of Doug Otis's suggestion to always
> > use a CmdSN and add a header flag indicating that the command should
> > be executed immediately at the target rather than waiting for those with
> > prior CmdSNs to arrive.  Doug's suggestion also consumes less space
> > in the header. 
> 
> Yes, i now understand Doug's proposal.  The "PDU sequencer" was
> new terminology which baffled me some.. :-)
> 
> His solution does seem like a cleaner approach (no target state)
> 
> In some ways, it reminds one of the M_FLUSH function used
> in the STREAMS layer.   If we stand back a bit, we see that the
> scenario is essentially the same -> Stream module processing is 
> normally asynchronous.   With M_FLUSH, the stream head desires to 
> clean out all the downstream module queues.  
> 
> 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.  
> 
> Do we have any numbers on how often ABORT_TASK/ABORT_TASK_SET actually 
> occurs in filesystem/SCSI workloads ?
> 
> regards,
> -Sandeep

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 7 Apr 2001 09:47:27 -0700

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