Bug 476793 - scsi_id returning garbage wwid for unpresented LUNs [NEEDINFO]
scsi_id returning garbage wwid for unpresented LUNs
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: udev (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Harald Hoyer
Depends On:
Blocks: 1049888
  Show dependency treegraph
Reported: 2008-12-17 02:03 EST by vijay
Modified: 2014-02-04 10:02 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-31 07:36:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
harald: needinfo? (vijayakumar)

Attachments (Terms of Use)
The suggested patch (2.23 KB, text/plain)
2008-12-17 22:13 EST, vijay
no flags Details

  None (edit)
Description vijay 2008-12-17 02:03:37 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):

How reproducible:

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.
Comment 1 Christophe Varoqui 2008-12-17 16:49:52 EST
why not just blacklist 360000000000000000000000000000000 ?
we can even add it to the build-in blacklist, if this non-intrusive method is sufficient.
Comment 2 vijay 2008-12-17 22:13:35 EST
Created attachment 327297 [details]
The suggested patch
Comment 3 vijay 2008-12-17 23:11:57 EST
The wwid need not always be 360000000000000000000000000000000, it can be any junk value.
Comment 4 Kiyoshi Ueda 2008-12-18 01:11:30 EST
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?
Comment 5 vijay 2008-12-18 01:35:19 EST
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.
Comment 6 Kiyoshi Ueda 2008-12-18 03:03:27 EST
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.
Comment 7 vijay 2008-12-19 00:50:08 EST
Ok, we agree the fix should be at the scsi id utility itself
Comment 8 Senthil Kumar V 2009-05-11 05:47:29 EDT
 Do you have any plan to fix this issue in getuid or in scsi id utility?
Comment 9 Harald Hoyer 2009-05-12 05:03:48 EDT
any patch for the scsi_id util present? Does the scsi_id of udev-141 work?
Comment 10 RHEL Product and Program Management 2014-01-31 07:36:25 EST
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

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