|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: aborting an immediate command with ABORT TASK
If the
Abort Task had its RefCmdSN == 7, then wouldn't this cause the problem David and
Tony point out (considering everything David said)?
Eddy
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.
As for the mapping - you
are right - I'll mark it for the final edit (whenever that happens).
Julo
| Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu
05/09/02 09:50
| To:
tonyb@cybernetics.com cc:
ips@ece.cmu.edu
Subject: RE: iSCSI:
aborting an immediate command with ABORT TASK
|
This
thread's taken a while to sort through, but there does appear to be a
problem in here.
> If the missing command was non-immediate, then
yes, the plug-in avoids > having to resend the missing command.
But, if the missing command was > immediate, then there is no hole
to plug. In this case, the spec requires > the target to plug a
hole which does not exist, which is the problem that I > am trying to
point out.
I'm working off of -15. Section 2.2.2.1 contains the
following statements:
CmdSN always contains the number to be assigned
to the next Command PDU.
Commands meant for immediate delivery
are marked with an immediate delivery flag; they MUST also carry
the current CmdSN.
So suppose CmdSN is 7, and the initiator sends an
immediate command with CmdSN 7 and then decides to abort it, and sends TASK
ABORT as an immediate command (CmdSN is 7 and not advanced). Suppose
the TASK ABORT crosses the response to successful completion of the
immediate command on the wire. At this point the following text in
Section 9.6.1 applies:
b) if the Referenced Task
Tag does not identify an existing task but if the CmdSN
indicated by the RefCmdSN field in the Task Man-
agement function request is within the valid CmdSN window (between
MaxCmdSN and ExpCmdSN), targets must consider the
CmdSN received and return the "Function complete"
response.
7 is still the CmdSN of the next non-immediate command to be
sent, so it is within the window (ExpCmdSN is also 7). Following
these directions, the Target considers CmdSN 7 to be received, and
advances its window. Now, when the initiator sends its next
non-immediate command (CmdSN=7), its CmdSN is outside the window, and the
target bit-buckets the command instead of executing it.
This went
awry because the task to be aborted was (implicitly) identified by its
CmdSN, and not its Task Tag resulting in an attempt to abort an immediate
command actually clobbering the next non- immediate one. I think Tony
gets credit for finding another problem.
While I'm in here, it also
appears that the text describing the mapping of iSCSI task management
response codes to SCSI service responses needs to change to map 1 (Task
does not exist) to FUNCTION COMPLETE rather than FUNCTION REJECTED to line
up with Section 6.2 of
SAM-2.
Thanks, --David --------------------------------------------------- David
L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA
01748 +1 (508) 249-6449 FAX:
+1 (508) 497-8018 black_david@emc.com Mobile: +1 (978)
394-7754 ---------------------------------------------------
Home
Last updated: Thu Sep 05 10:18:57 2002
11771 messages in chronological order
|