SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Abort task



    
    
    Pierre,
    
    I am not sure that I follow completely (and accurately) your line of
    thought  but if you have a multiple connection session the command
    numbering is meant to offer a total ordering.  Any of the scenarios you
    mention can't happen unless the target decides to deliver commands to the
    "SCSI layer" out of order.
    And even if it does deliver command out of order (there might be good
    reasons for it) it should build a "sync barrier" for those commands that
    mandate ordering.  This type of problem exist also in FCP (on a single
    connection!) and I assume that the thinking there is to use the per LU
    command ordering to avoid task management PDUs  (like clear a queue)
    arriving before the commands they are referring to.
    
    I hope this clarifies the issue.
    
    Julo
    
    Pierre Labat <pierre_labat@hp.com> on 09/01/2001 11:39:53
    
    Please respond to Pierre Labat <pierre_labat@hp.com>
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: Abort task
    
    
    
    
    Julian,
    
    
    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:52 2001
6315 messages in chronological order