|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI: Abort taskJulian, It seems that we need to specify more the "Abort task" to avoid some problems. Below are 3 points we should add in the spec: 1) An "Abort task" must be sent on the TCP connection that was used to send the command. This does not apply if the connection used for the command has been "logged out". In this case of course, the "Abort task" can be send on another connection and it will not hurt. It is to avoid that a command that was delayed in the network, finally make it after the "Abort task" as been processed. 2) When the initiator receives the "Abort task" response, if the ExpCmdRN returned in the "Abort task" response is <= CmdRN of the aborted task, the initiator must re-use this CmdRN for another task (any). 3) The target when receiving an "Abort task" for a task whose the CmdRN (retreived from the initiator task tag) is >= ExpCmdRN must not bridge this CmdRN. I mean by bridge: allow ExpCmdRN to pass the CmdRN value of the aborted task. It will be up to the initiator to send another command with the same CmdRN in order to allow the target to move ExpCmdRN over the CmdRN value of the aborted task. "3)" Is to prevent to following scenario: Two TCP connections 1 and 2 in the session ExpCmdRN = 2 a) the command with CmdRN = 3 is sent over connection1 b) the command with CmdRN = 4 is sent over connection 2 c) the command CmdRN = 4 reaches the target d) the initiator aborts the command 4 and bridges CmdRN=4 e) the target receives the command 3, and as CmdRN=4 is bridged, advances ExpCmdRN to 5 f) the initiator sends another command (not related with the aborted one) with CmdRN=4 g) the target drops this command because CmdRN is less than ExpCmdRN. "2)" needs to exist because if the initiator doesn't re-use the CmdRN the target will deadlock because ExpCmdRN will be stuck behind the CmdRN of the aborted command. An alternative to the points 2) and 3) would be the initiator not re-using the CmdRN of the aborted commands. But this requires the target to bridge all the CmdRNs of the Aborted tasks (need extra states) and anyway there is a scenario where it doesn't work. Hence this is a bad alternative. Scenario where it doesn't work: Session with 2 connections 1 and 2. ExpCmdRN=1 a) Command with CmdRN=4 is sent over connection1 b) Connection 1 drops and the command 4 will never make it to the target. c) A logout for the connection 1 is sent over connection 2 d) The initiator sends an "Abort task" (for the task CmdRN=4) over the connection 2 e) The target, from the referenced initiator task tag cannot find the CmdRN of the aborted task because the initiator task tag corresponds to nothing because the command has never been received. Hence the target is not able to bridge CmdRN=4 f) As the initiator does not re-use CmdRN=4 the target will deadlock when ExpCmdRN will be 4. Regards, Pierre
Home Last updated: Tue Sep 04 01:05:56 2001 6315 messages in chronological order |