Description of problem:
This is the same as sourceforge bug 1191229:
I'm filing this mainly for reference, and for the below
workarounds - I'm not sure we'll really fix this.
Basically the iscsi driver does its own lun scanning in
3.4.x and 3.6.x versions, and it's based on REPORT_LUNs
only with a bunch of bitmaps -- it does not take into
account the inquiry data, capacity, etc. Thus, if you
have a lun mapped, start the driver, then change that
lun on the target (e.g. resize, change to a different
lun, etc), an "iscsi reload" won't pick up the change
and tell the kernel about it -- it'll just see that
LUN0 is still mapped, and as a result, the kernel will
have stale LUN size data, etc.
There are a couple workarounds to this problem:
1) iscsi restart; This has the downside though of
blowing away all existing sessions and interfering with
any in-progress IO to all targets
2) make sure you do an "iscsi reload" after the device
has been removed on the target, then another "iscsi
reload" after you add it back. If your target has
ACL's for LUN lists then all you have to do it remove
the LUN ACL for that initiator, do an "iscsi reload",
add the ACL back, then another "iscsi reload".
3) explicitly use the /proc/scsi "remove-single-device"
and "add-single-device" commands to remove the lun from
the kernel, then add it back. In this case you don't
have to do an "iscsi reload", since the LUN was
originally mapped and the new LUN is now mapped as well
at LUN0. But adding and removing via the /proc/scsi
interface will update the kernel info to see the new
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I am planning to put a release note in U6 to describe the issue and the
I just wanted to add to this bug that I did not add this to the release notes. I
am in the middle of writing a RH KB note about how to rescan for both drivers. I
ran out of time and only had time to get the basic iscsi artcles to our writers,
but I will hopefully be able to add a reference to the rescan article if it is
up or add that note to the release notes in U7.
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.