RE: iSCSI: error recovery

["Douglas Otis" <dotis@sanlight.net>]

Julo,

An alternative to this feature would be to restrict the size of any write
operation.  Even on a 4GB transfer, this transfer could be limited to 500KB
transactions as example.  Loss of any transaction would only impact a
sub-portion of the exchange.  At the client side, residuals on error would
need to be recalculated to reflect the aggregate.  A command retry may
impact an idempotent exchange and thus cause an error should buffered data
be unrecoverable by being held on a different adapter.  Should the command
not be ordered, a complete retry will succeed whereas the iterative
acknowledgement can not in the case of a different adapter that does not use
global acknowledgements.  Although the underlying transport is reliable,
iSCSI acts as yet another transport layer.  With SCSI retries, iSCSI retries
and TCP retries all at the same time, reducing complexity of this additional
transport layer can only help improve predictable operation.

Doug

> Matt,
>
> Correct - but why is the assumption that iffish. Why would an adapter want
> to ack data it has still buffered?
> How can it help and what  gets simpler?
> Why would a tape controller doing a huge copy to a disk want to give up
> such an evidently good feature?
>
> Julo
>
> Matt Wakeley <matt_wakeley@agilent.com> on 31/10/2000 00:46:05
>
> Please respond to Matt Wakeley <matt_wakeley@agilent.com>
>
> To:   IPS Reflector <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI: error recovery
>
>
>
>
> julian_satran@il.ibm.com wrote:
>
> > 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.
>
> You are making the *big* assuption that an iSCSI initiator will "confirm"
> the
> receipt of this "numbered" data after the data has been transfered to
> initiator
> host memory.  What if it's buffered on the card somewhere, and the card
> dies
> and the system fails over to a different card?  (or perhaps an I/O
> subsystem
> fails and the system "fails over" to a standby subsystem) How is the
> initiator
> going to be absolutely sure that the "partial" I/O on the first card plus
> the
> "partial" I/O on the second card equal a complete error free I/O?
>
> Is this idea for something that rarely happens really worth the
> effort?  In
> the
> interests of simplicity, I propose that data not be numbered.
>
>
> >
> >
> > It is the target that will benefit and it is the target's decision to
> > number or not.
> >
> > Regards,
> > Julo
>
> -Matt
>
>
>
>