RE: Immediate Commands in iSCSI

[Julian Satran <Julian_Satran@xxxxxxxxxx>]

Jacob,

I do not want to appear offensive -
but did you consider the "larger picture"? Assuming that the
negotiation key or status is there and assuming that the target talks to
7 (seven) different initiators what would it tell each of them (it has
7 different sessions)? Should he reserve a quota for each of them - so
that it can meet what it declared? What should a target do with commands
that exceed the number? 

In iSCSI as a rule we avoided setting
or negotiating parameters that we don't need to set/negotiate and I think
the number of accepted immediate commands is one of them.

Julo

RE: Immediate Commands in iSCSI

Jacob_Cherian

to:

Julian Satran

12/03/07 04:06 PM

Cc:	ips, Nam_Nguyen

---

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

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