SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery



    
    
    please reread carefully my previous answer. Julo
    
    Santosh Rao <santoshr@cup.hp.com> on 09-05-2001 19:37:41
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    To:   IPS Reflector <ips@ece.cmu.edu>
    cc:
    Subject:  Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery
    
    
    
    
    > julian_satran@il.ibm.com wrote:
    
    > > > We could add the RefCmdSN and it may help plug-in the hole but unless
    the
    > > > Abort is ussued on the same connection as the original command we
    can't
    > > be
    > > > sure that the old-one will not pop-up (as we enable ExpCmdSN to move
    on
    > > we
    > > > don't have even the 2**31-1 protection bracket :-)). Thus sending in
    > > > another nop/abort on the same connection is still required.
    > > >
    > > > To simplify the whole process I will:
    > > >
    > > >  a - add RefCmdSN to the Task Management
    > > >  b - add a command not received yet to the answers
    > > >
    > > >  c - add a part to 7 reading:
    > > >
    > > > 1.1  How to Abort Safely a Command that Was Not Received
    > > >
    > > >    To abort safely a task for which the task abort answer is "Command
    Not
    > > >    Received Yet" the initiator must issue another abort command on
    the
    > > same
    > > >    connection as the original command unless this connection was
    logged
    > > out
    > > >    in which case it may send it on any connection.
    
    
    Julian,
    
    The above may not be sufficient, since a requirement for the Abort Task
    completion is that both the initiator & target can safely re-use their
    task tags and other resources following completion of the Abort Task. If
    the Abort Task is sent on another connection than the connection used
    for the original command [& that connection has not been logged out],
    then, there may be some in-flight PDUs from the target to the initiator
    for that command on the connection.
    
    Sending an Abort Task on another connection may cause the initiator to
    receive the Abort Task response indicating success on the other
    connection which then results in initiator freeing up its task tag and
    other resources used for that command. Thereafter, the stale PDUs on the
    original connection can show up at the initiator, causing problems.
    
    I would suggest that Abort Task be always sent on the same connection as
    the command, unless the connection used for that command has been logged
    out. Not doing so implies the initiator cannot safely re-use its task
    tag and other resources that were tied up for that I/O.
    
    Regards,
    Santosh
     - santoshr.vcf
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:43 2001
6315 messages in chronological order