Immediate commands do not create holes. Immediate
commands can be aborted ONLY if referenced by their ITT.
Again RefCmdSN is used only if the command is not
found by ITT - and then only to avoid having to send a duplicate
command.
Julo
----- Original Message -----
Sent: 30 August, 2002 21:29
Subject: RE: iSCSI: aborting an immediate
command with ABORT TASK
In my example, the
command with the Initiator Task Tag matching the Referenced Task Tag is not at
the target. When the target considers the command with RefCmdSN
received, it assumes _incorrectly_ that the command with RefCmdSN must have
Initiator Task Tag == Referenced Task Tag. That assumption can
be incorrect when immediate commands are used because multiple
commands with different Initiator Task Tags can have the same CmdSN.
This is just another way of looking at the problem, but the problem still
exists.
-----Original
Message----- From: Julian Satran
[mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 30, 2002 2:15
PM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu;
owner-ips@ece.cmu.edu Subject: Re: iSCSI: aborting an immediate
command with ABORT TASK Tony, As it was already
pointed out CmSN is a SECONDARY identifier - the primary being the Referenced
Task Tag. I was introduced to simplify
handling holes (commands discarded or arriving late). In your example A and B have different ITT or one of
them gets bumped. Julo
| "Tony Battersby"
<tonyb@cybernetics.com> Sent by: owner-ips@ece.cmu.edu
30/08/02 20:16 Please respond to tonyb
| To:
<ips@ece.cmu.edu> cc:
Subject: iSCSI: aborting an immediate
command with ABORT TASK
| It seems that an initiator attempting to abort an
immediate command may inadvertently cause the next non-immediate command to
be aborted instead. For example,
Initiator sends an immediate
command "A" with CmdSN 10. Initiator sends a non-immediate command "B" with
CmdSN 10. Initiator sends an immediate ABORT TASK command "C" with CmdSN 11
to abort command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task
Tag of "A").
If the target either: 1) Receives "C" before "A" or
"B", OR 2) Receives "C" before "B" but after executing and freeing
"A",
...then the target will not have a matching task for the abort in
its queue, and will consider CmdSN 10 received because it is inside the
valid CmdSN window. If the target then receives "B", it will silently
ignore the command because it is outside the valid CmdSN window. This
is obviously not what the initiator was trying to accomplish.
This
problem could be solved by adding a flag to the PDU for the ABORT
TASK command to indicate if the task to be aborted is immediate or
non-immediate. If the target does not have a matching task and the RefCmdSN
is inside the valid command window, then the target should consider the
CmdSN received only if the flag indicates that the task to be aborted is
non-immediate.
-----------------------
One other thing: for
draft 16, I recommend that the the following phrase: "... (i.e., with CmdSN
not higher than the task management command CmdSN) ..." in section 9.5.1
be changed to: "... (i.e., with CmdSN lower than the task management
command CmdSN) ...". This is for consistency with another sentence earlier
in the same paragraph.
Anthony J.
Battersby Cybernetics
|