Re: ISCSI: Error Recovery Level 0

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

From: <kevin_lemay@agilent.com>

> But devices supporting level 0 are not allowed to attempt any of the other recovery methods.

It is absolutely acceptable for an iSCSI entity to drop a connection on seeing a digest error.
Regardless of the negotiated error recovery level, both entities must deal with TCP exceptions
as a fact of life - as the state diagrams show.

To reiterate, the ErrorRecoveryLevel key specifies what each side is promising to minimally support.
This promise provides the guarantee to the initiator to resort to a sophisticated error recovery.
Negotiation of 0 *does not* mean that the entities must drop session on every error.

>
> It appears from reading the text for digest recovery, if a header disgest error occurs, that I just throw
away the PDU. If the pduLength was corrupted, then I am now out of sync. Do I wait for the initiator to drop
the connection?

No, you (target) may drop on your own.  Please note that *connection recovery* (requires ErrorRecoveryLevel=2)
is different from a simple *connection drop* (any recovery level).

Please also refer to an earlier thread initiated by Ken Sandars on this topic a couple of weeks ago.
--
Mallikarjun

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


>
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Wednesday, May 29, 2002 2:46 PM
> To: ips@ece.cmu.edu
> Subject: Re: ISCSI: Error Recovery Level 0
>
>
> Kevin,
>
> From: "LEMAY,KEVIN (A-Roseville,ex1)" <kevin_lemay@agilent.com>
> > I have the following question on error Recovery level 0.
> >
> > On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in
6.12.4.
>
> I can't find it.
>
> It's only saying that the minimally expected error recovery capabilities for level 0 are as described
> in 6.12.4, not that session recovery must be performed for every error....
>
> If you look in 6.12.4, it specifically states that session recovery is done only if all other recovery
> attempts fail.
>
> >
> > This seems to imply that:
> > If I have a multi-connection session were one connection experiences a digest error, then I must close all
> connections on the session, even killing IOs over the good connection.
> >
> > This is absurd!
>
> Indeed it would be if so implemented (even while it's legal).
>
> >Why not just close the one connection that has a problem and allow the IO to be restarted on one of the
other
> live connections? There is nothing wrong with the session, only a single connection.
>
> That's a reasonable recovery strategy (if it's a SCSI restart).
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
>
> >
> > I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would
allow
> for a much faster IO recovery without adding hardly any coding complexity that is required for level 1.
> >
> > Comments?
> >
> > Kevin Lemay
> >
>