Re: iSCSI: error recovery

[Matt Wakeley <matt_wakeley@agilent.com>]

julian_satran@il.ibm.com wrote:

> /<JS>
>
> The whole point about data numbering is to allow a target to discard
> read-data when read-data is hard to recover (as in tapes).  Once data is
> acked it is discarded. A target getting a command in restart mode will
> resend whatever data it has still buffered (not acked) and continue from
> there. The initiator would not e any wiser because it is not supposed to
> scoreboard.
>
> <JS>/

Julian,

The target should not through away data that is hard to recover until the
target has received notification that the *whole* I/O has successfully
completed at the initiator.  You must not have read my response (included
below) showing how complex it would be for an initiator to reliably piece
together two incomplete I/Os into one good I/O.

> > I assume that a clever target will keep only unacked data (the whole point
> > of data PDU numbering is to lower the amount of data a target has to keep
> > for recovery).
>
> I don't think there is any advantage to retransmitting only data that was not
>
> "acked".  Let's say the data was being sent over a tcp connection to
> initiator
> HBA #1 of a multi tcp connection iSCSI session.  I think for simplicity most
> iSCSI HBAs will inform the host driver of completed I/Os, not "partial" I/Os
> (especially indicating what was received and what wasn't).  When the
> connection
> is "failed over" to another connection, perhaps running on a different HBA,
> it
> will be much simpler to retry the whole I/O over the new connection, rather
> than piece together two partial I/Os.  Simpler is better isn't it?
>
> > At command restart it will resent what it has.
>
> No, command retry (restart) was meant to retry the whole I/O.  It was not
> meant to be "send what you think I didn't get".

-Matt