7.38. device-mapper-multipath
Updated device-mapper-multipath packages that fix numerous bugs and add various enhancements are now available for Red Hat Enterprise Linux 6.
The device-mapper-multipath packages provide tools for managing multipath devices using the device-mapper multipath kernel module.
Bug Fixes
- BZ#578114
- When the
kpartx
tool tried to delete a loop device that was previously created, and the udev utility had this loop device still open, the delete process would fail with theEBUSY
error andkpartx
did not attempt retry this operation. Thekpartx
tool has been modified to wait for one second and then retry deleting up to three times after theEBUSY
error. As a result, loop devices created bykpartx
are now always deleted as expected. - BZ#595692
- The
multipathd
daemon only checked SCSI IDs when determining World Wide Identifiers (WWIDs) for devices. However, CCISS devices do not support SCSI IDs and could not be used by Device Mapper Multipath. With this update,multipathd
checks CCISS devices for CCISS IDs properly and the devices are detected as expected. - BZ#810755
- Some device configurations in the
/usr/share/doc/device-mapper-multipath-0.X.X/multipath.conf.defaults
file were out of date. Consequently, if users copied those configurations into the/etc/multipath.conf
file, their devices would be misconfigured. Themultipath.conf.defaults
file has been updated and users can now copy configurations from it without misconfiguring their devices. Note that copying configurations from themultipath.conf.defaults
file is not recommended as the configurations in that file are built into dm-multipath by default. - BZ#810788
- Previously, Device Mapper Multipath stored multiple duplicate blacklist entries, which were consequently shown when listing the device-mapper-multipath's configuration. Device Mapper Multipath has been modified to check for duplicates before storing configuration entries and to store only the unique ones.
- BZ#813963
- Device Mapper Multipath had two Asymmetric Logical Unit Access (ALUA) prioritizers, which checked two different values. Certain ALUA setups were not correctly failing back to the primary path using either prioritizer because both values need to be checked and neither prioritizer checked them both. With this update, configuration options of both ALUA prioritizers now select the same prioritizer function, which checks both values as expected.
- BZ#816717
- When removing
kpartx
device partitions, themultipath -f
option accepted only the device name, not the full pathname. Consequently, an attempt to delete a mulitpath device by the full pathname failed if the device had thekpartx
partitions. Device Mapper Mulitpath has been modified to except the full pathname, when removingkpartx
device partitions and deleting process no longer fails in the described scenario. - BZ#821885
- Previously, the
multipath -c
option incorrectly listed SCSI devices, which were blacklisted by device type, as valid mulitpath path devices. As a consequence, Device Mapper Multipath could remove the partitions from SCSI devices that never ended up getting multipathed. With this update,multipath -c
now checks if a SCSI device is blacklisted by device type, and reports it as invalid if it is. - BZ#822389
- On reload, if a multipath device was not set to use the
user_friendly_names
parameter or a user-defined alias, Device Mapper Multipath would use its existing name instead of setting the WWID. Consequently, disablinguser_friendly_names
did not cause the multipath device names to change back to WWIDs on reload. This bug has been fixed and Device Mapper Mulitpath now sets the device name to its WWID if nouser_friendly_names
or user defined aliases are set. As a result, disablinguser_friendly_names
now allows device names to switch back to WWIDs on reload. - BZ#829065
- When the Redundant Disk Array Controller (RDAC) checker returned the
DID_SOFT_ERROR
error, Device Mapper Multipath did not retry running the RDAC checker. This behavior caused Device Mapper Multipath to fail paths for transient issues that may have been resolved if it retried the checker. Device Mapper Multipath has been modified to retry the RDAC checker if it receives theDID_SOFT_ERROR
error and no longer fails paths due to this error. - BZ#831045
- When a multipath vector, which is a dynamically allocated array, was shrunk, Device Mapper Multipath was not reassigning the pointer to the array. Consequently, if the array location was changed by the shrinking, Device Mapper Multipath would corrupt its memory with unpredictable results. The underlying source code has been modified and Device Mapper Multipath now correctly reassigns the pointer after the array has been shrunk.
- BZ#836890
- Device Mapper Multipath was occasionally assigning a WWID with a white space for AIX VDASD devices. As a consequence, there was no single blacklist of WWID entry that could blacklist the device on all machines. With this update, Device Mapper Multipath assigns WWIDs without any white space characters for AIX VDASD devices, so that all machines assign the same WWID to an AIX VDASD device and the user is always able to blacklist the device on all machines.
- BZ#841732
- If two multipath devices had their aliases swapped, Device Mapper Multipath switched their tables. Consequently, if the user switched aliases on two devices, any application using the device would be pointed to the incorrect Logical Unit Number (LUN). Device Mapper Multipath has been modified to check if the device's new alias matches a different multipath device, and if so, to not switch to it.
- BZ#860748
- Previously, Device Mapper Multipath did not check the device type and WWID blacklists as soon as this information was available for a path device. Device Mapper Multipath has been modified to check the device type and WWID blacklists as soon as this information is available. As a result, Device Mapper Multipath no longer waits before blacklisting invalid paths.
- BZ#869253
- Previously, the
multipathd
daemon and thekpartx
tool did not instruct thelibdevmapper
utility to skip the device creation process and let udev create it. As a consequence, sometimeslibdevmapper
created a block device in the/dev/mapper/
directory, and sometimes udev created a symbolic link in the same directory. With this update,multipathd
andkpartx
preventlibdevmapper
from creating a block device and udev always creates a symbolic link in the/dev/mapper/
directory as expected.
Enhancements
- BZ#619173
- This enhancement adds a built-in configuration for SUN StorageTek 6180 to Device Mapper Multipath.
- BZ#735459
- To set up persistent reservations on multipath devices, it was necessary to set it up on all of the path devices. If a path device was added later, the user had to manually add reservations to that path. This enhancement adds the ability to set up and manage SCSI persistent reservations using device-mapper devices with the
mpathpersist
utility. As a result, when path devices are added, persistent reservations are set up as well. - BZ#810989
- This enhancement updates the
multipathd init
script to load thedm-multipathd
module, so that users do not have to do this manually in cases when no/etc/multipath.conf
file is present during boot. Note that it is recommended to create themultipath.conf
file by running thempathconf --enable
command, which also loads thedm-multipath
module. - BZ#818367
- When the RDAC path device is in service mode, it is unable to handle I/O requests. With this enhancement, Device Mapper Multipath puts an RDAC path device into a failed state if it is in the service mode.
- BZ#839386
- This update adds two new options to the defaults and devices sections of the
multipath.conf
file; theretain_attached_hw_hander
option and thedetect_prio
option. By default, both of these options are set tono
in the defaults section of themultipath.conf
file. However, they are set toyes
in the NETAPP/LUN device configuration file. Ifretain_attach_hw_handler
is set toyes
and the SCSI layer has attached a hardware handler to the device, Device Mapper Multipath sets the hardware as usual. Ifdetect_prio
is set toyes
, Device Mapper Multipath will check if the device supports ALUA. If so, it automatically sets the prioritizer to thealua
value. If the device does not support ALUA, Device Mapper Multipath sets the prioritizer as usual. This behavior allows NETAPP devices to work in ALUA or non-ALUA mode without making users change to built-in config.In order forretain_attached_hw_handler
to work, the SCSI layer must have already attached the device handler. To do this, the appropriatescsi_dh_XXX
module, for instancescsi_dh_alua
, must be loaded before the SCSI layer discovers the devices. To guarantee this, add the following parameter to the kernel command line:rdloaddriver=scsi_dh_XXX
Updated device-mapper-multipath packages that fix one bug are now available for Red Hat Enterprise Linux 6.
The device-mapper-multipath packages provide tools for managing multipath devices using the device-mapper multipath kernel module.
Bug Fix
- BZ#988704
- Prior to this update, Device Mapper Multipath did not check for NULL pointers before dereferencing them in the sysfs functions. As a result, the multipathd daemon could crash if a multipath device was resized while a path device was being removed. With this update, Device Mapper Multipath checks for NULL pointers in sysfs functions and no longer crashes when a multipath device is resized at the same time as a path device is removed.
Users of device-mapper-multipath are advised to upgrade to these updated packages, which fix this bug.
Updated device-mapper-multipath packages that add one enhancement are now available for Red Hat Enterprise Linux 6.
The device-mapper-multipath packages provide tools for managing multipath devices using the device-mapper multipath kernel module.
Enhancement
- BZ#993545
- This update adds a new /etc/multipath.conf file default keyword, "reload_readwrite". If set to "yes", multipathd will listen to path device change events, and if the device has read-write access, it will reload the multipath device. This allows multipath devices to automatically have read-write permissions, as soon as the path devices have read-write access, instead of requiring manual intervention. Thus, when all the path devices belonging to a multipath device have read-write access, the multipath device will automatically allow read-write permissions.
Users of device-mapper-multipath are advised to upgrade to these updated packages, which add this enhancement.