Bug 156125

Description of problem:
This is the same as sourceforge bug 1191229:
http://sourceforge.net/tracker/index.php?func=detail&aid=1191229&group_id=26396&atid=387023

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
size, etc.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: