Subject: Re: aborting an out of sequence cmdSN

From: [email-masked]
Date: Wed, 18 Apr 2001 15:59:52 +0200

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 <[email-masked]> on 18/04/2001 01:10:17

Please respond to Santosh Rao <[email-masked]>

To:   Sandeep Joshi <[email-masked]>
cc:   [email-masked]
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

---

From: Santosh Rao <[email-masked]>
Date: Wed, 18 Apr 2001 10:00:43 -0700

Julian,

I understand that nothing in the current draft prevents usage of
connection allegiance for an abort task to flush the stale PDUs of a
command. 

However, as a target implementor, if such a guaranteed mechanism is not
mandated to flush stale PDUs of a command, targets will need to build
safeguards against possible stale PDUs from a command. Any such scheme
would cause targets to retire resources until a safe period (based on a
best guess !) has elapsed. The targets CANNOT depend on initiators
deploying this scheme in the absence of the spec mandating this and do
not have a guarantee that stale PDUs will not arrive after the Abort
Task has cleaned up the command at the target end.

Keeping in mind the above, I am asking that iSCSI mandate that the Abort
Task be sent on the same connection as the SCSI command being aborted.
In addition, [and this has been asked earlier], the iSCSI draft lacks a
section on I/O timeout handling under the error recovery section. Some
description must be provided on the actions an initiator should take on
an I/O timeout. (or timeout of other iSCSI PDUs).

For instance, should non-SCSI PDUs be timed ? (login, text, etc). If so,
what is their timeout values. What actions should an initiator take if
they time out. How is the task tag for that non-SCSI PDU cleaned up,
ensuring no stale PDUs are going to arrive for that task tag.

iSCSI Error Recovery descriptions MUST address task timeout handling. 

- Santosh