Bug 168801 - kernel dm multipath: ioctl support
kernel dm multipath: ioctl support
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
high Severity medium
: ---
: ---
Assigned To: Milan Broz
: FutureFeature
: 171318 (view as bug list)
Depends On:
Blocks: 207575 211071
  Show dependency treegraph
Reported: 2005-09-20 09:22 EDT by Narasimha Murthy
Modified: 2013-02-28 23:04 EST (History)
18 users (show)

See Also:
Fixed In Version: RHBA-2007-0304
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 19:24:00 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 Narasimha Murthy 2005-09-20 09:22:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)

Description of problem:
For supporting cluster applications, HP requires the DM devices to support ioctls for the following:
1. Bus reset.
2. Device reset.
3. SCSI verify/reserve/release commands.

Filing the request in the bugzilla for supporting specific ioctls, as per the discussions in the teleconf on 15th Sep'05.

Thanks and regards

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:

Additional info:
Comment 1 Alasdair Kergon 2005-09-20 16:58:10 EDT
The core issue is that ioctl() is designed to act on a single device - whereas a
device-mapper device has an arbitrary set of devices and mappings behind.

The ideal option would be to have an ioctl() extension which included additional
information for device-mapper to use to determine where to send the request.

The more realistic approach will be to support only restricted sets of ioctls on
restricted sets of device-mapper devices.

We need to determine exactly what we can support.

I think this particular request is:

    If the mapped device has exactly one target in its table and that target is
of type 'multipath' then support most (or all?) ioctls by handing them on to
exactly one path in a similar way to that in which I/O is processed.

Are there any ioctls for which this would cause problems?
Comment 3 Narasimha Murthy 2005-10-06 02:43:11 EDT
The Bus/device resets or inquiry commands will not have any effect if its done 
on any one of the paths. 

Will there be any effect if the above ioctls are executed through any one of 
the paths if the mapped device has multiple targets.
Comment 7 Narasimha Murthy 2005-10-20 08:46:13 EDT
We need support for some more ioctls like Inquiry, RAW_GETBIND and RAW_SETBIND.
Comment 9 Alasdair Kergon 2005-10-20 15:30:28 EDT
*** Bug 171318 has been marked as a duplicate of this bug. ***
Comment 13 Narasimha Murthy 2005-12-14 04:23:36 EST
Below are some thoughts,

DM multipathing target may need to only implement one ioctl that will pass 
through a SCSI commands. This will allow INQUIRE, TUR, and CAPACITY commands to 
be handled in the same way by DM without a lot of translations. The library 
calls to routines would return the results of an INQUIRY, TUR, or CAPACITY as 
needed, using the SCSI pass through ioctl.

It may be a good idea to leave ioctls like resets to be done through sysfs 
interface. It may allow the greater control over the SCSI-FC environment when 
this is implemented in the HBA driver. 
Comment 15 Ravichandra Krishnamurthy 2006-03-21 08:36:21 EST
When this is fixed, does it mean the following will work on a dm-multipath 
device consisting of either scsi or cciss class of disk device:
1. RAW_SETBIND and RAW_GETBIND would work on /dev/raw/rawctl to give details 
of what raw device dm-multipath target is bound to(get) and actually bind it to

2. Serial number(VPD page 0x80) and WWN(page 0x83) can be obtained from the 
INQUIRY ioctl.
Comment 28 Jay Turner 2006-12-12 12:53:31 EST
QE ack for 4.5.
Comment 31 Jason Baron 2007-01-02 13:28:15 EST
committed in stream U5 build 42.36. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 34 Red Hat Bugzilla 2007-05-01 19:24:00 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.