Re: aborting an out of sequence cmdSN

[julian_satran@il.ibm.com]

Santosh,

The version 06 (to appear today) addresses your concerns with regard to
Task management - although through the mechanism I was alluding all the
time.

At David Black's suggestion - I've added a section to chapter 7 explaining
how to properly handle task management using CmdSN.
It is only a note to implementers - nothing needed change.

The error recovery chapter is still work-in-progress.

I would also appreciate if you would "tone down" your notes - recall that
we are always limited by our own imagination.

Julo

Santosh Rao <santoshr@cup.hp.com> on 18/04/2001 19:00:43

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

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: aborting an out of sequence cmdSN




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


julian_satran@il.ibm.com wrote:
>
> 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
 - santoshr.vcf