|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"Julian, "6.7.1.1 Recovery Within-connection At the initiator, the following cases lend themselves to within-connection recovery: (1)Lost iSCSI numbered Response recognized by either receiving it with a data digest error or receiving a Response PDU with a higher StatSN than expected. The initiator MAY request the missing responses through SACK, in which case the target MUST reissue them. " To me, the following statement : "The initiator MAY request the missing responses through SACK, in which case the target MUST reissue them." implies that the target MUST be able to re-issue a SCSI Response PDU, when a Status SACK is received, which implies the target MUST maintain the I/O state information around [until StatSN is acknowledged.] Section 1.2.2.2 of my version of iSCSI rev 05 (taken from http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-05.txt) reads as follows : "1.2.2.2 Response/Status Numbering and Acknowledging Responses in transit from the target to the initiator are numbered. The StatSN (Status Sequence Number) is used for this purpose. StatSN is a counter maintained per connection. ExpStatSN is used by the initiator to acknowledge status. Status numbering starts after Login. During login, there is always only one outstanding command per connection and status numbering is not needed. The login response includes an initial value for status numbering. Satran, J. Standards-Track, Expire October 2001 12 iSCSI March 1, 2001 To enable command recovery the target MAY maintain enough state information to enable data and status recovery after a connection failure. A target can discard all the state information maintained for recovery after the status delivery is acknowledged through ExpStatSN. A large difference between StatSN and ExpStatSN may indicate a failed connection. Initiators and Targets MUST support the response-numbering scheme. " Can you please clarify where in the above section is there an example that Status SACK can be rejected by targets ? Further, the Reject PDU (Section 2.20.1) only allows a reject reason of Data SACK reject. There is no reason code of "Status SACK Reject". All this to me implies that Status SACK support is mandatory and targets MUST maintain I/O state information until the StatSN is acknowledged. Can you please clarify if this is not the case, and if so, what is the intent of the above text ? - Santosh julian_satran@il.ibm.com wrote: > > Santosh, > > I can't find the place where this is stated. SNACK as a PDU type is > mandated. But it can be rejected outright. > > 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 > > > But not specifying the mechanism for the more expensive one we make them > > non-interoperable. 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 |