Bug 168801
Summary: | kernel dm multipath: ioctl support | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Narasimha Murthy <narasimha.murthy> |
Component: | kernel | Assignee: | Milan Broz <mbroz> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 4.0 | CC: | agk, christophe.varoqui, coughlan, ddomingo, dmo, dwysocha, egoggin, jbrassow, jturner, kanderso, lmb, malcolm.demare, mbroz, pvrabec, rkenna, rvchan, sdavies, tranlan |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHBA-2007-0304 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-05-01 23:24:00 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: | 207575, 211071 |
Description
Narasimha Murthy
2005-09-20 13:22:22 UTC
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? 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. We need support for some more ioctls like Inquiry, RAW_GETBIND and RAW_SETBIND. *** Bug 171318 has been marked as a duplicate of this bug. *** 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. 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 (set). 2. Serial number(VPD page 0x80) and WWN(page 0x83) can be obtained from the INQUIRY ioctl. QE ack for 4.5. committed in stream U5 build 42.36. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/ 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. http://rhn.redhat.com/errata/RHBA-2007-0304.html |