RE: iSCSI: Recognizing Recovery R2Ts

[Nick Bellinger <nickb@attheoffice.org>]

David,

On Sun, 2002-09-15 at 18:08, Black_David@emc.com wrote:
> > 	The question is how does an initiator know when a R2T is a recovery
> > R2T and not a normal R2T?  The case I am referring is in regard to the
> > last paragraph in section 9.8 of iSCSI-v17-working:
> > 
> > "DataSequenceInOrder governs the buffer offset ordering in consecutive 
> >  R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST refer 
> >  to continuous non-overlapping ranges except for Recovery-R2Ts."
> > 
> > So the initiator is allowed to ignore the buffer offset in the case of 
> > DataSequenceInOrder=Yes when receiving a Recovery R2T,
> 
> No, the initiator is *never* allowed to ignore the buffer offset.  An
> R2T *always* describes the data that the Target wants transferred.
> 

Sorry,  left out a key word here.  I had intended to say "buffer offset
ordering". 

> > but how does the initiator know in fact an R2T is being used for
> > within-command recovery?  AFAICS there is no "Recovery bit" in the
> > R2T pdu, and am at a loss as to how the initiator would reliably
> > ascertain this situation.
> 
> A Recovery R2T is a retry of part or all of some previous R2T.
> Whether the initiator knows this depends on whether it saw the
> previous R2T.  The initiator's behavir should not be affected -
> it is supposed to respond to R2Ts (including retries, as allowed
> by DataSequenceInOrder - see Section 11.19) until the target gets
> all the data it wants and issues a SCSI Response.
> 

Im still lost here.  Please consider the example:

MaxDataSegmentLength=8192, MaxBurstLength=32768, ImmediateData=No,
InitialR2T=Yes.

I-> ISCSI_INIT_SCSI_CMND, EDTL=131072, SCSI Opcode WRITE_10 
T-> ISCSI_TARG_R2T, DDTL=32768, Offset=0
I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=0, DataSN=0, DataLength=8192
I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=8192, DataSN=1, DataLength=8192
I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384, DataSN=2, DataLength=8192

(Data Payload Fails on DataSN=2)

T-> ISCSI_TARG_RJT, Reason=Data Digest (Payload) Error
I-> ISCSI_INIT_SCSI_DATA_OUT, F_BIT, Offset=24576, DataSN=3,
DataLength=8192

Can the Target either: (Are both of these legal?)

	a) Accept DataSN=3 even though DataSN=2 Failed
	   Only request retransmisson of Failed DataOut
	T-> ISCSI_TARG_R2T (Recovery) DDTL=8192, Offset=16384

	or b) Discard DataSN=3, Request retransmission of
	      all DataOut from failed to MaxBurstLength  
	T-> ISCSI_TARG_R2T (Recovery) DDTL=16384, Offset=16384

Initiator: (This is where im confused)
	Received either a) or b),  and knows the R2T is a Recovery
	R2T because the DDTL is not 32768 (MaxBurstLength or rest of 	the
original EDTL) and Offset is not 32768.  

Following a)
I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192
I-> ISCSI_INIT_SCSI_DATA_OUT F_BIT, Offset=24576, DataSN=3,
DataLength=8192

Following B)
I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=16384 DataSN=2, DataLength=8192

Target:
	MaxBurstLength is Completed:
T-> ISCSI_TARG_R2T, Offset=32768, DDTL=32768

I-> ISCSI_INIT_SCSI_DATA_OUT, Offset=32768, DataSN=0, DataLength=8192

Etc....

Your statement "Whether the initiator knows this depends on whether it
saw the previous R2T" is still confusing to me.  The logic used in the
above example (EDTL and Offset) I assume is incorrect.  Would you mind
elaborating with a specific example of the proper method of doing so?

Thanks David!

	Nicholas Bellinger - Pyxtechnologies.com
 

> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 249-6449            FAX: +1 (508) 497-8018
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>  
>