|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: aborting an immediate command with ABORT TASK
How
about another bit in the abort that says it is aborting an immediate command and
hence does not advance the window?
Eddy
I
don't think we want to. The TM made immediate are done so with good reason -
to allow expedited consideration. And
there are no known scenarios (to us) in which it does not work.
Julo
| Eddy Quicksall
<eddy_quicksall@ivivity.com> Sent by: owner-ips@ece.cmu.edu
05/09/02 15:46
| To:
"'Black_David@emc.com'" <Black_David@emc.com>,
tonyb@cybernetics.com
cc:
ips@ece.cmu.edu
Subject: RE: iSCSI:
aborting an immediate command with ABORT TASK
|
Can
we say that aborts with the immediate bit only abort commands with
the immediate bit? And then say that the window is not advanced under
that situation?
Eddy
-----Original Message----- From:
Black_David@emc.com [mailto:Black_David@emc.com] Sent: Thursday, September
05, 2002 2:51 AM 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
|