Subject: Data re-read from Device Server

From: "Rahul Bhagwat" <[email-masked]>
Date: Fri, 2 Nov 2001 19:38:22 +0530

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

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 02 Nov 2001 10:21:55 -0500

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: