Immediate Commands in iSCSI

[<Jacob_Cherian@xxxxxxxx>]

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