Re: Data re-read from Device Server

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

I believe the implicit assumption is that the ULP is holding 
the right locks.  Since retransmission has been requested, the 
particular command has not yet completed at the initiator.  
That, in turn, implies that the ULP is still waiting for the 
data and has not yet released its relevant locks.

-Sandeep


> Rahul Bhagwat wrote:
> 
> 
> Hi,
> 
> Section 8 mentions "It is also assumed that at target, incoming  data
> (read data)
> MAY be kept for recovery or it can be re-read from a device server."
> 
> Is it assumed here that the data from the device server is idempotent
> i.e will not
> change when tried to re-read. If that is not the case and we have more
> than one
> Data In PDU being sent in the response (for one of which a
> retransmission is
> requested), it will result in in-correct view of the data being given
> to the initiator.
> 
> As an example, consider that the following response needs to be given
> 
>   ------------------
>  | 1 | 2 | 3 | 4 |
>   -----------------
> 
> which gets transmitted in two Data In PDUs like this
> 
>   --------                  ---------
>  | 1 | 2 |                |  3 | 4 |
>   --------                  ---------
> 
> Now if a re-read generates
> 
>   ------------------
>  | 1 |  3 | 4 | 5 |
>   ------------------
> 
> and retransmission is requested for 2nd PDU. It will get transmitted
> like
> 
>   --------
>  | 4 | 5 |
>   --------
> 
> which means the initiator neither got 1,2,3,4 nor got 1,3,4,5 (both of
> which are
> valid snapshots at some point in time), instead it got 1,2,4,5 which
> never existed
> at the target.
> 
> If we try to re-read only data pertaining to retransmitting PDU, the
> problem persists.
> 
> Regards,
> Rahul