|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: error recoveryjulian_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
Home Last updated: Tue Sep 04 01:06:35 2001 6315 messages in chronological order |