Re: iSCSI: error recovery

[julian_satran@il.ibm.com]

Matt,

I think I read your note and I still maintain that the target will fare
better and the initiator does not have to do anything different.

When failing over the initiator will reissue the command (including all
scatter gather lists) to the new HBA. It is the target that will send only
the buffers he has and as long as the initiator is not scoreboarding it
does not have to do anything different the second time than first.

It is the target that will benefit and it is the target's decision to
number or not.

Regards,
Julo

Matt Wakeley <matt_wakeley@agilent.com> on 26/10/2000 23:20:57

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: error recovery




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