Bug 156125 - iscsi 3.6.2 lun scanning does not see lun size change
iscsi 3.6.2 lun scanning does not see lun size change
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: iscsi-initiator-utils (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike Christie
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-27 15:11 EDT by Dave Wysochanski
Modified: 2008-04-07 00:42 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:04:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Wysochanski 2005-04-27 15:11:15 EDT
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:
Comment 1 Tom Coughlan 2005-04-29 08:38:28 EDT
I am planning to put a release note in U6 to describe the issue and the
workarounds. 
Comment 2 Mike Christie 2005-10-24 12:35:25 EDT
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.
Comment 3 RHEL Product and Program Management 2007-10-19 15:04:03 EDT
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:
http://www.redhat.com/security/updates/errata/
 
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.

Note You need to log in before you can comment on or make changes to this bug.