Bug 215469 - blacklisting of local scsi devices needs to be more finegrained
Summary: blacklisting of local scsi devices needs to be more finegrained
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: device-mapper-multipath   
(Show other bugs)
Version: 4.4
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Ben Marzinski
QA Contact: Corey Marthaler
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-14 07:38 UTC by NetApp filed bugzillas
Modified: 2010-01-12 02:27 UTC (History)
11 users (show)

Fixed In Version: RHEA-2007-0256
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 17:45:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2007:0256 normal SHIPPED_LIVE device-mapper-multipath enhancement update 2007-05-01 17:35:42 UTC

Description NetApp filed bugzillas 2006-11-14 07:38:21 UTC
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 21:06:59 UTC
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 20:36:54 UTC
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 19:16:58 UTC
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 17:45:40 UTC
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.