From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 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): rpm-sg3_utils-1.06-3 How reproducible: Always 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.: sg5 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"]