Bug 476793

Summary: scsi_id returning garbage wwid for unpresented LUNs
Product: Red Hat Enterprise Linux 5 Reporter: vijay <vijayakumar>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: agk, bmarzins, bmr, bzeranski, christophe.varoqui, dwysocha, egoggin, heinzm, iannis, junichi.nomura, kueda, lmb, lmiksik, phinchman, prockai, psklenar, senthil-kumar.veluswamy, tranlan, vijayakumar
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-31 12:36:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1049888    
Attachments:
Description Flags
The suggested patch none

Description vijay 2008-12-17 07:03:37 UTC 
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.
Comment 1 Christophe Varoqui 2008-12-17 21:49:52 UTC 
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-18 03:13:35 UTC 
Created attachment 327297 [details]
The suggested patch
Comment 3 vijay 2008-12-18 04:11:57 UTC 
The wwid need not always be 360000000000000000000000000000000, it can be any junk value.
Comment 4 Kiyoshi Ueda 2008-12-18 06:11:30 UTC 
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 06:35:19 UTC 
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 08:03:27 UTC 
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 05:50:08 UTC 
Ok, we agree the fix should be at the scsi id utility itself
Comment 8 Senthil Kumar V 2009-05-11 09:47:29 UTC 
Hello,
 Do you have any plan to fix this issue in getuid or in scsi id utility?
Comment 9 Harald Hoyer 2009-05-12 09:03:48 UTC 
any patch for the scsi_id util present? Does the scsi_id of udev-141 work?
Comment 10 RHEL Program Management 2014-01-31 12:36:25 UTC 
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 11 Red Hat Bugzilla 2023-09-14 01:14:53 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days