|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Task management questionsI think Gwendal has a point. This and section 9.4 are very hard sections to read and understand. Perhaps we did not mean all that is said here. In addition too, or in support of Gwendal, I also found that the paragraph that begins "For all these Functions..." in 3.5.1 needs to be Harmonized with the "Abort Task Must..." Paragraph since they are clearly at odds, especially since the Abort Task is one of the functions addressed in the previous paragraph. But I simply do not understand how the following statement: "...the target MUST deliver to the initiator good status for all aborted task for which no status was delivered yet. The task management response MAY be issued by the target immediately after marking all tasks to be aborted." can be made to work with section 9.4 which goes to great pain to "silently discard" commands that are covered by the Abort but have not yet been executed. (See the last item b on page 156.) I think silently discard means do not return Status. After we sort out the above, we still have to deal with the differences right within 9.4. That is the first item d on page 156 states: "Note: Any entries that had been marked as a candidate for cleanup have now been delivered by the target to its SCSI layer. The SCSI layer will have to determine if they are to be aborted." and the last item b states: "remove the oldest barrier list item and evaluate all queued entries that have a CmdSN field less than ExpCmdSN, removing and silently discarding each queued command that meets the criteria for cleanup candidacy (as specified by the task management function)" This means DO NOT SEND THEM TO SCSI ! Therefore, they had not been delivered by the target to its SCSI layer as stated above. So we have one place saying that SCSI layer will determine, and the other place finding a method not to send them to SCSI. I understand what is being attempted here (to meet the requirements of SAM-2 (1157-D) section 5.5.2 that states "... no notification that the task(s) have been aborted shall be returned to the initiator...." however, our documentation needs some clean-up to make it consistent. This is NOT a change to the protocol, just a clean up of our documentation, but the way it is now it is hard to perform the protocol and follow the documentation in this specific area. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Gwendal Grignou <ggrignou@silverbacksystems.com>@ece.cmu.edu on 11/23/2001 02:03:02 PM Sent by: owner-ips@ece.cmu.edu To: "ips" <ips@ece.cmu.edu> cc: Subject: Task management questions I have a question about the section 3.5.1 page 69. The paragrah starting with "ABORT TASK MUST",the last sentene says "The task management response MUST be issued after the command status (if any) was issued." : it means the initiator will receive, on the same connection, a status for the aborted task and AFTER, a response for the task management function. In the paragraph before (starting with "For all these functions,",), it is specified that the target should send a status for all aborted tasks, but the task management response can happen at any time after the task management request has been received by the target "The task management response MAY be issued by the target immediately after marking all tasks to be aborted." Why such a difference between "ABORT TASK" function and other functions ? About, "LOGICAL UNIT RESET", it is stated "the target MUST behave as dictated by the Logical Unit Reset function in [SAM2]." However, in SAM2, taks should be aborted as described in section 5.6 of SAM2, which says , in section 5.6.2, about initiator aborting their own task "When an initiator causes its own task(s) to be aborted, no notification that the task(s) have been aborted shall be returned to the initiator other than the completion response for the command or task management function action that caused the task(s) to be aborted and notification(s) associated with related effects of the action (e.g., a target reset unit attention condition)." Does it means the iSCSI target may not send a status for the aborted tasks in case of a "LOGICAL UNIT RESET" ? (and subsequently for TARGET RESET [WARM or COLD] which triggers LOGICAL UNIT RESET for each LUs [SAM2, section 5.8.6]). It does not match with the requirement in the paragraph concerning all the task management functions in general. Can you elaborate more on those requirements ? Thanks a lot, Gwendal.
Home Last updated: Sun Nov 25 11:17:58 2001 7900 messages in chronological order |