|
[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 |