SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI - started countdown to 11


    • To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
    • Subject: RE: iSCSI - started countdown to 11
    • From: "Buck Landry" <blandry@crossroads.com>
    • Date: Fri, 22 Feb 2002 17:29:39 -0600
    • content-class: urn:content-classes:message
    • Content-Transfer-Encoding: 8bit
    • Content-Type: text/plain;charset="iso-8859-1"
    • Sender: owner-ips@ece.cmu.edu
    • Thread-Index: AcG7w4IYA1aF26x8QqipXjS0qDUpVgAJyGyA
    • Thread-Topic: iSCSI - started countdown to 11

    Two yes/no questions about the new Task Mgmt Function Request/Response wording.
    
    1) Does ABORT_TASK_SET/CLEAR_TASK_SET apply to an immediate cmd with the same CmdSN?  Or to rephrase, in this example scenario:
    
    T -> I (Nop-in, ExpCmdSN = 3)
    I -> T (Scsi Command, CmdSN = 3, Immediate bit set)
    I -> T (Task Mgmt Func Reqest, ABORT TASK SET, CmdSN = 3, Immediate bit set)
    
    .. is the scsi command aborted?
    
    The statement in section 9.5.1,
    
    "Task management requests must act on all commands having a CmdSN lower than the task management CmdSN"
    
    .. would resolve this nicely ("no") but in the same section, the wording
    
    "According to [SAM2] for all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN)"
    
    ...  implies that the task management response covers all tasks w/ equal or lower CmdSN while the request itself only covers tasks w/ lower CmdSN.
    
    -----
    
    2) For CLEAR TASK SET, does the target waiting behavior, 
    
    "the target on its part, MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests" 
    
    .. include tasks that originated from a different initiator than the one that sent CLEAR TASK SET?  Everything in the draft points to "yes" (I think), and I kindof actually like this.  But I'm (somewhat) suprised that, given a scenario with two sessions attached to the same scsi target:
    
    session "A": I -> T (Scsi Write Cmd, lun = 8, tag = 2)
    session "A": T -> I (R2T, tag = 2)
    session "B": I -> T (Task Mgmt Function Request CLEAR TASK SET, lun = 8)
    
    .. that the target would require the cooperation of session "A"'s initiator and network connection in order to deliver a Task Mgmt Function Response to session "B".  I suppose, if this cooperation did not occur, then eventually a timeout would fire, the affected task could just be forcefully killed, and a task management response could be sent on session "A".. is that the way it's supposed to work?
    
    Thanks for your consideration,
    --buck
    
    
    
    
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Friday, February 22, 2002 10:05 AM
    To: ips@ece.cmu.edu
    Subject: iSCSI - started countdown to 11 
    
    
    
    Dear colleagues, 
    
    I've put on my site a "working" version of the draft labeled 10-90. 
    Only the pdf version (with change bars vs. 10) is available. 
    I'll soon get out also a text version - without a TOC but otherwise usable. 
    
    Julo
    


Home

Last updated: Fri Feb 22 19:18:05 2002
8863 messages in chronological order