Bug 215469 - blacklisting of local scsi devices needs to be more finegrained
blacklisting of local scsi devices needs to be more finegrained
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ben Marzinski
Corey Marthaler
Depends On:
  Show dependency treegraph
Reported: 2006-11-14 02:38 EST by NetApp filed bugzillas
Modified: 2010-01-11 21:27 EST (History)
11 users (show)

See Also:
Fixed In Version: RHEA-2007-0256
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 13:45:40 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 2006-11-14 02:38:21 EST
Description of problem:
Currently there is no entry for blacklisting of scsi devices in the default 
templates of multipath package.
This makes the user assume to use the following setting convention (which is 
in the template for ide drives) for scsi devices also.

The problem is that the same setting for a scsi device can be problematic:
^sd[a] leads both to sda, sdaa, sdab ....
Hence it blacklists other devices where we only wanted to blacklist the single 
local sda scsi device.

We propose the inclusion of the following settings in the default templates 
for multipath.conf to assist users.
which specifically means to blacklist only and only the sda device.

How reproducible:

Steps to Reproduce:
1. Add as many devices till sdz is reached. the next device would be sdaa
2. Try blacklisting the devices, devnode "sda"
3. It blacklists all devices starting with sda.
Actual results:
It is blacklisting all devices all devices starting with sda

Expected results:
Should blacklist only device sda.

Additional info:
Comment 1 Ben Marzinski 2006-12-01 16:06:59 EST
People shouldn't blacklist individual devices this way. Using the devnode method
of blacklisting is fine for knocking out whole types of devices, but since there
is no guarantee that the device registered as /dev/sda on one boot will be
registered as /dev/sda on the next, blacklisting individual devices by devnode
is risky and not recommended. People should blacklist the devices by wwid
instead. I realize that people don't do this often, and unless new devices are
added, it's
really almost never a problem to use the devnode method, but it's still not ideal.

I suppose that I should add a comment saying something like this to the
Comment 2 NetApp filed bugzillas 2006-12-03 15:36:54 EST
Thats right. It does make a lot of sense blacklisting devices using the WWID
instead of device names in the multipath.conf file. I am aware of the 'scsi_id'
command which can be used to retrieve the WWID of a SCSI device as in:
'scsi_id -p 0x83 -g -s /block/<SCSI device>

But this command does not always work for local disks (which need blacklisting).
On one of my hosts, the above command gave a blank output. On another one, it
gave the following output:

[root@lnx200-127 ~]# scsi_id -p 0x83 -g -s /block/sda
0:0:0:0: sg_io failed status 0x8 0x0 0x0 0x2         
0:0:0:0: sense key 0x5 ASC 0x24 ASCQ 0x0             
0:0:0:0: Unable to get INQUIRY vpd 1 page 0x83.

So is there any simple foolproof method to obtain the WWID of a SCSI device?
Comment 3 NetApp filed bugzillas 2006-12-04 14:16:58 EST
Apparently "scsi_id -g -u -s /block/<SCSI device>" seems to work fine for all
cases including the ones described above. The unique device id generated by this
command could be used for blacklisting SCSI disks in the multipath.conf file.
Comment 10 Red Hat Bugzilla 2007-05-01 13:45:40 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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