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:Julian_Satran@xxxxxxxxxx]
Sent: Monday, December 03, 2007 1:23 AM
To: Cherian, Jacob
Cc: ips@xxxxxxxx; Nguyen, Nam
Subject: Re: 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
|
|
|
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
