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

[Santosh Rao <santoshr@cup.hp.com>]

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