Re: Immediate Commands in iSCSI

[Julian Satran <Julian_Satran@xxxxxxxxxx>]

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

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
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips