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




    Sorry - I've missed it.

    Clear task set is an "unpleasant feature". Obviously iSCSI can't do anything it does not know about (other initiators) but we assume that SCSI knows how to take care of it (SCSI has to do the clear task set).  The rest is a matter of implementation.

    Julo




    "Buck Landry" <blandry@crossroads.com>

    23-02-02 09:50

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        
            Subject:        RE: iSCSI - started countdown to 11

           


    ok, that's cool.  I was worried about the single connection case, where an initiator might *expect* some determinative behavior :-)
     
    I'm pressing my luck here but... did you have an off-the-top-of-your-head answer for my second question as well?  (scan for "2)" in this message if you don't know what I'm talking about) .. guess I was wondering if you had considered all the interesting consequences.
     
    thanks,
    --buck
    -----Original Message-----
    From:
    Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent:
    Saturday, February 23, 2002 12:20 AM
    To:
    Buck Landry
    Subject:
    RE: iSCSI - started countdown to 11


    Buck,


    Hard to get a short answer to this question.

    Immediate commands have some "non-determinism".

    If you do what you suggested on a single connection session then the answer is yes.

    If you do it on a multiple connection session - your mileage may vary...

    If the command arrived before abort it will be aborted. If not...

    Moreover - even a later immediate command arriving before the abort will be aborted.

    The text say quite explicitly that iSCSI hands over to SCSI the abort function.

    With immediate commands we have no control on when a command reaches SCSI.



    Julo


    "Buck Landry" <blandry@crossroads.com>
    Sent by: owner-ips@ece.cmu.edu

    23-02-02 01:29

           
           To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>

           cc:        

           Subject:        RE: 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: Sun Feb 24 03:18:21 2002
8872 messages in chronological order