RE: Immediate Commands in iSCSI

The goal of the new status or key is to help the initiator to know the
correct number of immediate commands that the target supports. The issue
with overloading a status that does clearly define the error condition
is that it does help in achieving interoperability between the myriad of
initiators and targets that are out there. I was looking to see if there
was another way that I had not considered.

 

Jacob

 

 

From: Julian Satran [mailto:[email protected]] 
Sent: Monday, December 03, 2007 1:23 AM
To: Cherian, Jacob
Cc: [email protected]; Nguyen, Nam
Subject: Re: [Ips] Immediate Commands in iSCSI

 


It looks to  me that the Reject response with reason 0x06 should be
enough for the initiator to handle the situation you describe. 
If the TM are the cause then each of those has a response indicating
termination. After receiving a reject an initiator should reissue new
TMs only after getting back one or more responses.  The initiator may
even accurately guess the number of commands the targets is capable of
handling per connection and per LU. The only case in which this handling
may be awkward is over a WAN but if you are operating over a WAN and TM
performance is your only worry you are in good shape :-) 

Julo 



 

[Ips] Immediate Commands in iSCSI

 

Jacob_Cherian 

to: 

ips 

12/03/07 05:23 AM

 

Cc: 

Nam_Nguyen

	

 

________________________________





RFC 3720 states: 

The number of commands used for immediate delivery is not limited and
their delivery for execution is not acknowledged through the numbering
scheme. Immediate commands MAY be rejected by the iSCSI target layer due
to a lack of resources. An iSCSI target MUST be able to handle at least
one immediate task management command and one immediate
non-task-management iSCSI command per connection at any time. 

  

With storage systems that have very large number of logical units, we
run into an issue when we use LU Reset or Abort Task for reset recovery.
I couldn't find a way to tell an initiator how many immediate commands a
target can accept. The issue with this is that if we have to issue
multiple task management commands and it is more than what the target
can accept, it will reject the task management request. Since we don't
know why it was rejected, we will have to escalate the reset. This can
be very disruptive with nodes that have very large number of logical
units. There may be two ways to resolve this: 

  

1)      Define a new Text negotiation key for number of outstanding
immediate commands supported. Unlike non-immediate (data) commands where
we can send TASK SET FULL, there is no way for a target to report in the
Task Management Function Response PDU that is unable to process the
current request before it is out of resources.  The default vaule for
this new key can be 1, so if this key is not negotiated initiators can
assume one per connection. 

2)      Define a new value for the Response field in the Task Management
Function Response PDU for reporting that the target cannot process the
request currently. 

  

Any suggestions on how to resolve this? 

  

Thanks, 

Jacob 
_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips
<https://www1.ietf.org/mailman/listinfo/ips>

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips