Bug 249805 - [NetApp-S 4.4 bug] "sg_map -sd" fails to show 'sd*' device mapping entries on continuous LUN mapping and unmapping
[NetApp-S 4.4 bug] "sg_map -sd" fails to show 'sd*' device mapping entries on...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sg3_utils (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Phil Knirsch
Depends On:
  Show dependency treegraph
Reported: 2007-07-27 02:36 EDT by NetApp filed bugzillas
Modified: 2015-03-04 20:18 EST (History)
1 user (show)

See Also:
Fixed In Version: 4.5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-07 06:33:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description NetApp filed bugzillas 2007-07-27 02:36:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070713 Firefox/

Description of problem:
We have observed that on continuous LUN mapping and unmapping (from NetApp filers)the sg to sd device mappings shown by "sg_map -sd" suddenly disappear even for the LUNs that are not unmapped.

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

How reproducible:

Steps to Reproduce:
1. Keep mapping LUNs, one by one,(say 10 LUNs in total) on the filers.

2. On each LUN mapping, issue scsi rescan command (e.g. in iSCSI configured host, use "/etc/init.d/iscsi reload") and ensure sg to sd device mappings are being updated using "sg_map -sd".

3. Keep unmapping the previously mapped LUNs (one by one).

4. On each LUN unmap, issue scsi rescan command and keep observing "sg_map -sd"  entries.

Actual Results:
(1) It can be seen that all on a sudden (say, after unmapping the 5th LUN), the sg to sd mappings (shown by "sg_map -sd") have disappeared (expect for the hard drives connected through scsi bus).

(2) Also, before the entries disappear (as described above), we can see stale sg entries, e.g.:
Suppose there are 3 sg-sd mapping corresponding to 3 LUNs as shown below in the format of "sg_map -sd" output (a part of the output):

sg5  sdc
sg6  sdd
sg7  sde

When the LUN corresponding to sdc is unmapped and scsi rescan is done, the "sdc" entry is removed but sg5 is still seen as a stale entry, i.e.:
sg6  sdd
sg7  sde

Expected Results:
(1) The entries for the mapped LUNs should not disappear.

(2) The stale entries should not be there. i.e. in the example provided in (2) of
"Actual Results" section, on removal of the LUN corresponding to "sdc", the sg entry ("sg5" in above example) should also be removed from "sg_map -sd" output.

Additional info:
This error is seen with "sg3_utils-1.06-3" driver which is shipped with RHEL 4U4.
We have seen this error even with RHEL 4U2 (not tested on RHEL 4U3).

However, we have not observed this issue with RHEL 4U5. Probably because, RHEL 4U5 is shipped with "sg3_utils-1.22-3.1" driver.

Also, we tried to upgrade the "sg3_utils-1.06-3" driver on RHEL 4U4 to "sg3_utils-1.21-1" downloaded from "http://sg.torque.net/sg/p/sg3_utils-1.21-1.i386.rpm". And we observed that we do not face the problem. 

Please suggest if we can recommend our RHEL 4U4 customers to upgrade the default sg driver to the ones mentioned above. It might be feasible for the existing customers to upgrade from RHEL 4U4 to RHEL 4U5 just for one particular component.

Please provide your recommendations for the afore-said issue.

[Putting it as "high serverity", because due to missing entries on "sg_map -sd", the existing/mapped LUNs can not be seen from the host. So, we consider this as "loss of data"]

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