Re: iSCSI: revised error recovery hierarchy

["Mallikarjun C." <cbm@rose.hp.com>]

Santosh,

....
> pdu and a count within the driver of the number of data pdu's received on
.....
> The above recovery scheme is not documented in Section 7.4 as a means of
> recovering from data digest errors on iscsi data pdu's.

I suggest the following opening comments in section 7 for your
consideration.
 
        Many of the recovery details in an iSCSI implementation are a
local 
        matter, beyond the scope of protocol standardization.  However,
some 
        external aspects of the processing must be standardized, to
ensure 
        interoperability.  This section (and the corresponding appendix
in 
        more detail) describes a general model for recovery, in support
of 
        interoperability.

What you describe is certainly an implementation choice, complying with
protocol expectations.  But as it does not affect the wire protocol(that
this chapter strives to capture), it isn't stated as a *protocol*
choice.  
That is generally the rule of thumb that ERT and myself followed for 
editing this chapter.  Hope that explains the rationale. 

>....a session logout is usable to
> recover from digest errors on status pdu's.....

True, as with any error!  Section 7.11 and 7.11.4 clearly call this
out.  That's why session logout/recovery is not listed as an option 
in every place.

I will however go ahead and add that a "close the connection" flavor
of Logout is a legal protocol-allowed option for lost status PDUs (in
addition to the recovery Logout that you pointed out).  

Thanks.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


Santosh Rao wrote:
> 
> Arpakorn Boonkongchuen wrote:
> 
> > >Any initiator that does not implement SNACK will have to perform session
> > >logout & re-login as the error recovery on digest errors that occurs on
> > >the status PDU.
> >
> > ok but do you see a problem if it is a data PDU?
> 
> None. An Abort Task should be usable to recover from a data digest error on
> a Data-In PDU.
> 
> One could also let the task run to completion and determine that an I/O
> underrun has occurred based on a comparision of the ExpDataSN in the status
> pdu and a count within the driver of the number of data pdu's received on
> that scsi cmd. This method is simplet and does not require any abort task
> usage.
> 
> The above recovery scheme is not documented in Section 7.4 as a means of
> recovering from data digest errors on iscsi data pdu's. This mechanism
> should be considered for inclusion in Section 7.4, since it is a simple
> technique to recover from data digest errors and does not require any abort
> task to be issued.
> 
> > >This is because of the current SNACK mechanism which will not allow the
> > >initiator to acknowledge any further Status PDUs once a hole occurs in
> > >the StatSN. The only way to workaround a hole in the StatSN sequence is
> > >to either use a Status SNACK or to do a session logout.
> >
> > A session logout is a pretty drastic measure. I wonder whether it
> > suffices to just log out and relogin on that particular connection
> > only?
> 
> Either a "connection logout for recovery" or a session logout is usable to
> recover from digest errors on status pdu's when the initiator does not
> support SNACK usage.
> 
> Section 7.4 is missing the usage of session logout as a recovery mechanism
> for digest errors on Status PDUs.
> 
> Regards,
> Santosh