RE: iSCSI: aborting an immediate command with ABORT TASK

["Julian Satran" <Julian_Satran@il.ibm.com>]

----- Forwarded by Julian Satran/Haifa/IBM on 05/09/02 16:54 -----

Julian Satran 05/09/02 16:53

To:        <tonyb@cybernetics.com>         cc:                 From:        Julian Satran/Haifa/IBM@IBMIL         Subject:        RE: iSCSI: aborting an immediate command with ABORT TASKLink

Again no - there was no hole filed and the second 7 gets through. Julo

"Tony Battersby" <tonyb@cybernetics.com> 05/09/02 16:23 Please respond to tonyb

To:        Julian Satran/Haifa/IBM@IBMIL, <Black_David@emc.com>         cc:        <ips@ece.cmu.edu>         Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002 8:27 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate command with ABORT TASK

> The next command can't be clobered. Abort Task acts on command  up to 6
> (included) but not 7- and it has to be on the same connection as the
> aborted command. That insures that it will abort the first immediate but
> not the non-immediate after.

Ok, here's the gotcha:

The initiator sends a non-immediate command with CmdSN 7 on a different
connection before sending the immediate ABORT TASK for the first immediate
command.  The ABORT TASK is sent on the same connection as the immediate
command with CmdSN 7 to be aborted, but a different connection than the
non-immediate command with CmdSN 7.  The ABORT TASK will carry a CmdSN of 8,
and the target may receive the ABORT TASK before it receives the
non-immediate command with CmdSN 7, because they are sent on different
connections.  If this happens, the target considers CmdSN 7 received and
then discards the non-immediate command with CmdSN 7 when it finishes
receiving it on the other connection.

Tricky, tricky, tricky...

Tony