RE: iSCSI: aborting an immediate command with ABORT TASK

["Tony Battersby" <tonyb@cybernetics.com>]

> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Black_David@emc.com
> Sent: Tuesday, September 03, 2002 7:21 PM
> To: tonyb@cybernetics.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI: aborting an immediate command with ABORT TASK
>
>
> Tony,
>

> > > 2) The race between an immediate command finishing normally
> > > (causing the target to free the command and forget its
> associated ITT)
> > >  and the initiator aborting it

>
> That's not correct.  In case 2) the ABORT TASK always succeeds no
> matter how the race turns out - SAM-2 Section 6.2 says:
>
> 	If the logical unit supports this function, a response of
> 	FUNCTION COMPLETE shall indicate that the task was aborted
> 	or was not in the task set.
>
> The words "or was not in the task set" are the crucial ones.  In
> case 2), the ABORT TASK always returns FUNCTION COMPLETE, and
> there may
> or may not be a response from the aborted task prior to that FUNCTION
> COMPLETE, but there MUST NOT be one afterwards.

I am not really concerned about the response code to the ABORT TASK.  My
concern is that the initiator may end up plugging a CmdSN hole when it
shouldn't.  From Section 9.6.1 (draft 15),

"...targets must consider the CmdSN received and return the "Function
complete" response."

I don't have a problem with returning the "Function complete" response.  I
do have a problem with the target considering the CmdSN received if the
initiator intended to abort an immediate command.

Tony