Responding to my own comment (since I seem to have done such a fine job of
"aborting" this email thread).....
I think it'd be a good idea to elaborate on LU Reset, and the two
flavors of Target Reset in a formal IETF doc.
I am concerned that the current lack of detailed specification would
allow targets that might even cause silent data corruptions to qualify as
RFC 3720-compliant.
Here are what I believe to be semantics applicable to all TMF requests
that can potentially terminate multiple tasks. I do not know the IETF
process well enough here, but I suggest that we consider this text
replacing the existing section 10.6.2 in RFC 3720 - so the new text can
cover all the TMFs that can impact multiple tasks. This is basically a
superset of the current 10.6.2 semantics.
Comments are welcome.
Mallikarjun
-----------------------------------------------------------------------
10.6.2. Task Management Actions on Requests Affecting Multiple Tasks
The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET,
TARGET WARM RESET, and TARGET COLD RESET Task Management function requests
consists of the following sequence of actions in the
specified order on each of the entities.
The initiator:
a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET
WARM RESET/TARGET COLD RESET request.
b) Continues to respond to each target transfer tag received
for the "affected" (*) tasks.
c) Receives any responses that the target may provide for some
tasks among the affected tasks (may process them as usual
because they are guaranteed to be valid).
d) Receives the task management response, thus concluding
all the tasks in the set of affected tasks.
The Target:
a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT
RESET/TARGET WARM RESET/TARGET COLD RESET request.
b) Waits for all currently valid target transfer tags of the
affected tasks to be responded.
c) Based on the CmdSN ordering, waits (concurrent with the
wait in step (b)) for all commands of the affected tasks
to be received. In the case of target-scoped requests
(i.e. TARGET WARM RESET and TARGET COLD RESET), all the
commands that are not received, as at the end of step (b),
in the command stream however can be considered to have
been received with no command waiting period - i.e. the
entire CmdSN space upto the CmdSN of the task management
function can be "plugged" (refer section 6.9 on how aborting
a specific task can implicitly plug the CmdSN of the task
being aborted) at the end of step (b).
d) Propagates the TMF request to and receives the response
from the target SCSI layer.
e) Takes note of last-sent StatSN on each of the connections
in the iSCSI session(s) (one or more) sharing the affected
tasks, and waits for acknowledgement of each StatSN (may
solicit for acknowledgement by way of a NOP-In). If some
tasks originate from non-iSCSI I_T_L nexi then the means by
which the target insures that all affected tasks have
returned their status to the initiator are defined by the
specific non-iSCSI transport protocol(s).
f) Sends the task set management response to the issuing
initiator.
[*] "affected" tasks:
ABORT TASK SET: All outstanding tasks for the I_T_L nexus
identified by the LUN field in the ABORT TASK SET
task management function.
CLEAR TASK SET: All outstanding tasks in the task set for the LU
identified by the LUN field in the CLEAR TASK SET
task management function.
LOGICAL UNIT RESET: All outstanding tasks from all initiators for
the LU identified by the LUN field in the LOGICAL
UNIT RESET task management function.
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from
all initiators across all LUs that the issuing
session has access to on the SCSI target device
hosting the iSCSI session.
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
