Description of problem:
The file iscsi-limits.h specifies a low number for ISCSI_CMDS_PER_LUN
(currently 12). This will impact performance when IOs take longer to
complete on a target (i.e. consider the case of random reads), and the
initiator would benefit from increasing this beyond 12.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Reduced performance with higher latency IO workloads (e.g. random IO)
Better performance with higher latency IO workloads (e.g. random IO)
Fix has already been checked into sourceforge 3-6 branch to increase
IOs per LUN from 12 to 32.
Since we're seeing lockups with RHEL3, U4 kernel (see bugzilla
145818), we probably need to tread more carefully here, as this has
the potential to change the memory consumption characteristics of the
iscsi driver, and potentially lead to more problems. Note that this
is not a request to increase the can_queue value, so it might not be a
big deal. However, it needs to be fully tested and not just put in
there without much testing.
Hi Dave, this request is on my list for U5. I have already started
testing it, and will continue, with an eye on the outcome of BZ 145818.
I decided not to make this change because it could make the problem in BZ 145818
worse. Once we have (at least a partial) workaround for BZ 145818, then we will
increase the queue depth.
FYI - just had another internal (netapp) customer asking about this.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.