Subject: Re: [Ips] Recovery and ERL=0

From: [email-masked]
Date: Wed, 5 Mar 2008 18:53:07 -0500

Prafulla,

This discussion is about data digest errors only, as with a header
digest error, the PDU type may have been affected by the corruption.
 
Section 6.7 applies regardless of the error recovery level, but some
of the options are not available at error recovery level 0.  I believe
that what you describe is acceptable at error recovery level 0, but
note that the following additional text (from Section 6.7) applies to
data digest errors at the target:
 
  If the target chooses to implement this option, it MUST wait to
  receive all the data (signaled by a Data PDU with the final bit
  set for all outstanding R2Ts) before sending the response PDU.
  A task management command (such as an abort task) from the
  initiator during this wait may also conclude the task.

For the initiator, aborting the task affected by a data digest error
may involve sending a task management function to the target.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Deuskar, Prafulla
	Sent: Wednesday, February 13, 2008 1:03 PM
	To: [email-masked]
	Subject: [Ips] Recovery and ERL=0

	With ERL=0 and Multiple Connections/Session what options does an
Initiator have for error recovery?

	Session recovery seems very heavy weight with MCS - Does section
6.7 in RFC only apply to within-a-command' or 'within-a-connection' data
recovery classes?

	For ex: In case of digest error can I do the following and still
be considered compliant with RFC with ERL=0

	If it is an iSCSI data PDU with digest error - abort the task
and terminate the command with an error

	If it is an iSCSI response PDU with digest error - logout the
connection  (abort all commands associated with the connection)

	Thanks,

	Prafulla

_______________________________________________
Ips mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Thu, 6 Mar 2008 09:03:43 +0200

Prafulla,

As David said - in your first case you may either wait for the response or 
issue an abort immediately.
In both cases you may have to handle some additional recovery at the SCSI 
level as you have "dropped" a command that may be part of a sequence.
For the response digest error logging out is an option but not technically 
mandatory (gray area) - but again you may have to handle (regardless of 
how you do it) some additional recovery at SCSI level.
Please note that higher recovery levels would allow you to avoid (in most 
cases) the need for recovery at SCSI level.

Julo

From:
[email-masked]
To:
<[email-masked]>, <[email-masked]>
Date:
03/06/08 01:54 AM
Subject:
Re: [Ips] Recovery and ERL=0

Prafulla,

 

Thanks,
--David

                 From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Deuskar, Prafulla
                 Sent: Wednesday, February 13, 2008 1:03 PM
                 To: [email-masked]
                 Subject: [Ips] Recovery and ERL=0

                 With ERL=0 and Multiple Connections/Session what options 
does an
Initiator have for error recovery?

                 Session recovery seems very heavy weight with MCS - Does 
section
6.7 in RFC only apply to within-a-command' or 'within-a-connection' data
recovery classes?

                 For ex: In case of digest error can I do the following 
and still
be considered compliant with RFC with ERL=0

                 If it is an iSCSI data PDU with digest error - abort the 
task
and terminate the command with an error

                 If it is an iSCSI response PDU with digest error - logout 
the
connection  (abort all commands associated with the connection)

                 Thanks,

                 Prafulla