Red Hat Bugzilla – Bug 476793
scsi_id returning garbage wwid for unpresented LUNs
Last modified: 2014-02-04 10:02:59 EST
Description of problem: Whenever a LUN is unpresented from the array side and multipath –v3 command is run, a new invalid multipath device is getting created with wwid 36000000000000000. Most of the storage arrays return a wwn of 0x6000000000000000 for unpresented LUN’s. RHEL multipath-tools treat this as a new device and create a multipath device out of it. Version-Release number of selected component (if applicable): device-mapper-multipath-0.4.7-22 2.6.18-125.el5 How reproducible: Always Steps to Reproduce: 1. present a lun to the host 2. run multipath -v3 3. unpresent the lun for the array 4. run multipath -v3 Actual results: New invalid device will be created mpath11 (360000000000000000000000000000000) dm-38 HP,####### [size=977M][features=1 queue_if_no_path][hwhandler=0] \_ round-robin 0 [prio=0][enabled] \_ 3:0:5:3 sdac 65:192 [failed][faulty] \_ 3:0:6:3 sdap 66:144 [failed][faulty] \_ 2:0:6:3 sdc 8:32 [failed][faulty] \_ 2:0:7:3 sdp 8:240 [failed][faulty] Expected results: The invalid device should not be created Additional info: Multipath-tools have to be modified to detect the invalid LUN’s and reject these devices. One of the ways to do this is by verifying if we are getting proper prio value for that device. The code can be modified to reject devices which donot respond with proper prio value. This change is already available in SLES OS.
why not just blacklist 360000000000000000000000000000000 ? we can even add it to the build-in blacklist, if this non-intrusive method is sufficient.
Created attachment 327297 [details] The suggested patch
The wwid need not always be 360000000000000000000000000000000, it can be any junk value.
The patch in Comment#2 looks like just a work-around, so it will make the code difficult to understand in the future. Shouldn't we fix the kernel or wwid getting tools not to return wwid for such unpresented LUNs if possible?
Yes. getuid callout routine has to be fixed. Also the patch in comment#2 has to be included, because we may want to reject the devices that doesn't return proper prio value.
Re: Comment#5 I still disagree with the patch. We can get no benefit from calling get_prio() for PATH_DOWN paths, since those paths probably always return invalid prio value, -1. And pathinfo() is often called from multipathd not only multipath, so if we call get_prio() for PATH_DOWN paths, many unnecessary error messages may be displayed until those paths come back to PATH_UP. And for your information, we are already rejecting paths having invalid prio value in libmultipath:configure.c:coalesce_paths(). So I think if we get the fix in getuid or kernel, all your requirements will be satisfied.
Ok, we agree the fix should be at the scsi id utility itself
Hello, Do you have any plan to fix this issue in getuid or in scsi id utility?
any patch for the scsi_id util present? Does the scsi_id of udev-141 work?
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.