|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: aborting an immediate command with ABORT TASK
I
don't see that fact when I read the spec. 9.5.5 RefCmdSN implies that the
RefCmdSN may be used if the Referenced Task Tag (ITT) is not with the target
anymore. And, I think that is David and Tony's point.
I may
have missed it someplace ... can you please point out where it says or
implies "an immediate is aborted based on ITT"?
Eddy
No need - it works always as it is. An immediate is aborted based on
ITT or not at all.
Add to it the fact
that they are on the same connection and immediates are not reassigned
and everything works AS IS.
What am I missing?
Julo
|
| Eddy Quicksall
<eddy_quicksall@ivivity.com>
05/09/02 16:02
|
To:
Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall
<eddy_quicksall@ivivity.com>
cc:
"'Black_David@emc.com'" <Black_David@emc.com>,
ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com
Subject:
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
-----Original
Message-----
From: Julian Satran
[mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 05, 2002
9:00 AM
To: Eddy Quicksall
Cc: 'Black_David@emc.com';
ips@ece.cmu.edu; owner-ips@ece.cmu.edu;
tonyb@cybernetics.com
Subject: RE: iSCSI: aborting an immediate
command with ABORT TASK
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:56 2002
11771 messages in chronological order
|
