Re: aborting an out of sequence cmdSN

[julian_satran@il.ibm.com]

First the current draft does not stop you from doing what you want - it
just does not mandate it.
Second with CmdSN now you have a better chance - before handing the command
over to SCSI task management
mark all the relevant commands in the iSCSI queue as non-deliverable to a
LUN or all LUNs or keep a stack of barriers for active aborts (I assume
that this is a reasonably low number) to the same effect.

Julo


Santosh Rao <santoshr@cup.hp.com> on 18/04/2001 01:10:17

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Sandeep Joshi <sandeepj@research.bell-labs.com>
cc:   ips@ece.cmu.edu
Subject:  Re: aborting an out of sequence cmdSN




I'd think option 1 is the simplest (with the caveat that the task mgmt
PDU referred to is the Abort Task.) and only impacts the affected
command/task.

Pierre Labat and I have asked for this 4 months ago. (See :
http://ips.pdl.cs.cmu.edu/mail/msg02958.html). The concept of connection
allegiance should be extended to include the Abort Task. Also,
connection allegiance should apply to the task (which spans multiple
commands in the case of linked commands.), allowing for a deterministic
clean up of stale PDUs of the task through the use of Abort Task.

- Santosh

Sandeep Joshi wrote:

>
> So our options for abort_task boil down to..
> (1) use connection allegiance for TASK MGMT PDU.
> (2) reject all commands prior to cmdSN of TASK MGMT PDU.
> (3) cmdSN of original task is sent with TASK MGMT PDU and
>     target at the iSCSI layer keeps state.
> (4) iSCSI initiator retains state for deleted tasks to ensure
>     that R2T/Scsi Responses are appropriately handled.
 - santoshr.vcf