SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"



    julian_satran@il.ibm.com wrote:
    
    > The reason we made SACK and status recovery
    > practically a MUST is that without them we are bound to have only session
    > drop as an alternative.
    > If the target does not keep any information after it has sent out status it
    > can't even retry a command.  And if it can retry a command it should be
    > able to do SACK.
    > 
    > But perhaps there is a place in the market for the kind of devices Somesh
    > is suggesting that do all recovery at SCSI level (and that can't copy a
    > terabyte of data without a session drop).
    
    Julian,
    
    I fail to see why deploying recovery schemes other than SACK/SNACK will
    cause session drop to occur. Initiators can choose to use the command
    "retry" as a recovery or just error the command to the SCSI ULP and let
    is retry. This does not imply a session [or connection] drop. (?)
    
    - Santosh
    
    
    > 
    > If that is true (which I doubt) we can make SNACK support optional.
    > 
    > Julo
    > 
    > "Mallikarjun C." <cbm@rose.hp.com> on 05/04/2001 04:09:46
    > 
    > Please respond to cbm@rose.hp.com
    > 
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
    > 
    > >
    > >Santosh,
    > >
    > >I can't find the place where this is stated. SNACK as a PDU type is
    > >mandated. But it can be rejected outright.
    > 
    > Sorry, you agreed that status SACK is mandatory in ERT forum last
    > week in response to my comments.  Has there been a change in your opinion?
    > 
    > Attached is the email in a long email thread (issue 3) where you agreed
    > to make this explicit in rev06.
    > --
    > Mallikarjun
    > 
    > Mallikarjun Chadalapaka
    > Networked Storage Architecture
    > Network Storage Solutions Organization
    > MS 5668   Hewlett-Packard, Roseville.
    > cbm@rose.hp.com
    > 
    > >1.2.2.2 show explicitely that SACK can be rejected. We can add a protocol
    > >specific parameter in the target Logical Unit Control Page (non-setable)
    > by
    > >which the target will indicate support for SNACK.
    > >
    > >Julo
    > 
    > Santosh Rao <santoshr@cup.hp.com> on 04/04/2001 23:53:32
    > 
    > Please respond to Santosh Rao <santoshr@cup.hp.com>
    > 
    > To:   Julian Satran/Haifa/IBM@IBMIL
    > cc:   Jon Hall <jhall@emc.com>, ips@ece.cmu.edu
    > Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
    > 
    > julian_satran@il.ibm.com wrote:
    > >
    > > Jon,
    > >
    > > Inexpensive implementation are always free to do away with recovery. That
    > > si true for targets too.
    > 
    > That's not the interpretation one gets from reading the spec and prior
    > discussions on this list. Per the spec, support for Status SACK is
    > mandatory while support for data SACK is optional.
    > 
    > IOW, targets MUST retains state information to satisfy a potential
    > status SACK request.
    > 
    > - Santosh
    begin:vcard 
    n:Rao;Santosh 
    tel;work:408-447-3751
    x-mozilla-html:FALSE
    org:Hewlett Packard, Cupertino.;SISL
    adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
    version:2.1
    email;internet:santoshr@cup.hp.com
    title:Software Design Engineer
    x-mozilla-cpt:;21088
    fn:Santosh Rao
    end:vcard
    


Home

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