SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    No Subject



    
    From: Pierre Labat <pierre_labat@hp.com>
    Organization: Hewlett Packard ATM-SISL
    X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
    X-Accept-Language: en
    MIME-Version: 1.0
    To: Dave Nagle <bassoon@yogi.ece.cmu.edu>
    Subject: Re: 
    References: <200007071849.OAA12781@yogi.ece.cmu.edu>
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    
    >
    > > Hello,
    > >
    > > In the last teleconf it has been stated that :
    > >  -> in case of a droped TCP connexion, a command that was on the flight
    > >       must be replayed on a new TCP connexion going through the same
    > >       service delivery port. This, because SAM-2 requires that all that
    > > concern
    > >       one command must flow through the same delivery port.
    > >
    > > But, because the recovery is done at the command level, why not
    > > abort this command on the target (the target will abort/cancel locally
    > > all the commands on the flight for the dropped TCP connexion),
    > > and replay the command on another link (other service delivery port).
    >
    > The command cannot be aborted and replayed because some devices (tapes for
    > example) cannot abort a command and then replay it.  That is the whole reason
    > FCP-2 was created for Fibre Channel.
    
    But this will happen only when the TCP connexion drops, that will be
    very seldom. Most of the time the problems are handled by TCP itself. Hence
    as the probability of TCP drop is very low why not restart the whole operation
    for the tapes and have a quick recovery for other devices switching on another
    port? Anyway trying to open a new TCP connexion on the same port
    doesn't guarantee that the tape operation will recover. If the TCP connexion
    drops it can be because of a link or adapter failure, you have better way to try
    
    another path.
    
    
    >
    >
    > >
    > > As the command will be totally restarted we don't need some intermediate
    > >
    > > command state that would need to be maintained per port.
    > > We can cleanup what was ongoing for this command on the initial port
    > > and restart drom scratch on the alternate port.
    > >
    > > It doesn't hurt SAM-2 because the replay of the command is a whole
    > > new command.
    > > Of course iSCSI must change the LUN in the headers to take into account
    > > the new service delivery port.
    >
    > But iSCSI does not have visibility to LUN mapping.  That is at a layer above
    > iSCSI.
    
    Ok, let say iSCSI layer warns the layer above and the layer above do the work.
    
    Regards,
    
    Pierre
    
    >
    >
    > >
    > >
    > > The big advantage is that it can speed up the recovery.
    > > 1) It is likely that if the TCP connexion dropped through a service
    > >   delivery port, the attempt to open a new one through the same
    > >   SDP will fail.
    > >
    > > 2) Replaying the command through an alternate link is faster
    > >   than waiting for the establishment of new TCP connexion.
    > >
    > > Regards,
    > >
    > > Pierre
    >
    > Matt Wakeley
    > Agilent Technologies
    


Home

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