8.28. device-mapper-multipath

Bug Fixes

BZ#975676

Device Mapper Multipath (DM-Multipath) did not test pointers for NULL values before dereferencing them in the sysfs functions. Consequently, the multipathd daemon could terminate unexpectedly with a segmentation fault if a multipath device was resized while a path from the multipath device was being removed. With this update, DM-Multipath performs NULL pointer checks in sysfs functions and no longer crashes in the described scenario.

BZ#889429

Prior to this update, the multipathd daemon did not start listening to udev events (uevents) until all the multipath paths that were discovered on system startup had been configured. As a consequence, multipathd was unable to handle paths that were discovered in the meantime. This bug has been fixed and multipathd now handles all paths as expected in the described scenario.

BZ#889441

Due to incorrectly ordered udev rules for multipathd, link priority was not set for multipath paths when creating the multipath device using initramfs udev rules. Consequently, the /dev/disk/by-uuid/<uuid> symbolic links pointed to multipath paths instead of the multipath device. This could lead to boot problems under certain circumstances. With this update, the multipathd udev rules have been ordered correctly so that the aforementioned symbolic links point to the multipath device as expected.

BZ#902585, BZ#994277

Previously, DM-Multipath did not allocate enough space for the sysfs "state" attribute. Consequently, when a path was switched to the "transport-offline" state, a buffer overflow was triggered, resulting in an error message being logged into the system log. Also, DM-Multipath did not handle correctly paths in the "quiesce" state, which resulted in unnecessary failure of these paths. With this update, DM-Multipath allocates enough space to store all valid values of the sysfs "state" attribute. Paths in the "quiesce" state are now moved to the "pending" state, which prevents the paths from failing.

BZ#928831

Previously, DM-Multipath did not verify whether the kernel supported the "retain_attached_hw_handler" mpath target feature before setting it. Consequently, the multipath devices which had set "retain_attached_hw_handler" did not work on machines with an older kernel without this feature support. With this update, DM-Multipath checks that the kernel supports the "retain_attached_hw_handler" feature before setting it. The multipath devices now work as expected on systems with older kernels utilizing newer versions of DM-Multipath.

BZ#995251

In certain setups, the Redundant Disk Array Controller (RDAC) did not mark a path as down if the target controller reported an asymmetric access state of the target port to be "unavailable". As a consequence, the multipathd daemon repeatedly attempted to send I/O to an unusable path. This bug has been fixed, and multipathd no longer sends I/O to unusable paths in this case.

BZ#1011341

Previously, the kpartx utility did not take into account the actual sector size of the device when creating partitions for the MS-DOS partition table, assuming a fixed size of 512 bytes per sector. Therefore, kpartx created partitions that were 1/8 of the proper size if the device with a sector size of 4 KB used the MS-DOS partition table. With this update, kpartx verifies the device's sector size and calculates the proper partition size if the device uses the MS-DOS partition table.

BZ#892292

When displaying multipath topology for the specified multipath device, DM-Multipath unnecessarily obtained WWIDs for all the multipath paths for all the configured multipath devices. Consequently, the "multipath -l" command took an extensively longer time to complete than expected, especially on systems containing a large number of multipath devices. This behavior has been changed and when displaying topology of the specified multipath devices, the multipath command now acquires WWIDs only for paths belonging to these devices.

BZ#974129

DM-Multipath previously set the fast_io_fail_tmo configuration option before setting the dev_loss_tmo option. However, a new value of fast_io_fail_tmo is not allowed to be greater than or equal to the current value of dev_loss_tmo. Therefore, when increasing values of both options and sysfs failed to set fast_io_fail_tmo due to the aforementioned limitation, even dev_loss_tmo could not have been set to a new value. With this update, if a new value of fast_io_fail_tmo would be too high, DM-Multipath sets it to the highest valid value, that is, the current value of dev_loss_tmo minus one. When setting both, the fast_io_fail_tmo and dev_loss_tmo options, dev_loss_tmo is now increased first.

BZ#889987

When the detect_prio option was set, DM-Multipath did not verify whether a storage device supports asymmetric logical unit access (AULA) before setting up the AULA prioritizer on the device. Consequently, if the device did not support AULA, multipathd failed to detect AULA priority of the paths and emitted an error message to the system log. This bug has been fixed so that DM-Multipath now verifies whether a path can be set with AULA priority before setting up the AULA prioritizer on the storage device.

BZ#875199

Due to a NULL pointer dereference bug, multipathd could terminate with a segmentation fault when removing a failed path to a multipath device. This update adds a NULL pointer test to the code, preventing multipathd from a fail in this scenario.

BZ#904836

When creating partitions for the GUID Partition Table (GPT), the kpartx utility did not account for the actual sector size of the devices with the sector size other than 512 bytes. As a result, kpartx created partitions that did not match the actual device partitions. With this update, kpartx correctly calculates a size of the created partitions to matches the actual block size of the storage device.

BZ#918825

The kpartx utility did not properly release file descriptors allocated for loopback devices, causing file descriptor leaks. This update corrects the kpartx code, and kpartx no longer leaves file descriptors open after releasing loopback devices.

BZ#958091

When the multipath command failed to load a multipath device map with read/write permissions, the multipath device could have been incorrectly set with read-only access. This happened because the multipath command always retried reloading the map table with read-only permissions even though the failure was not caused by an EROFS error. With this update, multipath correctly reloads a multipath device with read-only permissions only if the first load attempt has failed with an EROFS error.

BZ#986767

Previously, DM-Multipath did not prevent creating a multipath device to a tapdev device, which cannot be a subject to multipath I/O due to an unexpected path format. Consequently, if a multipath device was created on top of a tapdev device, multipathd terminated with a segmentation fault on the tapdev device's removal from the system. With this update, tapdev devices are blacklisted by default and this problem can no longer occur.

Enhancements

BZ#947798

This update adds a new default keyword, "reload_readwrite", to the /etc/multipath.conf file. If set to "yes", multipathd listens to path change events, and if the path has read-write access to the target storage, multipathd reloads it. This allows a multipath device to automatically grant read-write permissions, as soon as all its paths have read-write access to the storage, instead of requiring manual intervention.

BZ#916667

The multipathd daemon now includes major and minor numbers of the target SCSI storage device along with the path's name to messages that are logged upon path's addition and removal. This allows for better association of the path with the particular multipath device.

BZ#920448

In order to keep naming consistency of multipath devices, DM-Multipath now sets the smallest available user-friendly name even when the /etc/multipath/bindings file has been edited manually. If the smallest user-friendly name cannot be determined, DM-Multipath retains previous behavior and sets the multipath device symbolic name to the next available largest name

BZ#924924

A new default parameter, "replace_wwid_whitespace", has been added to the /etc/multipath.conf file. If set to "yes", the scsi_id command in the default configuration section returns WWID with white space characters replaced by underscores for all applying SCSI devices.