Red Hat SummitChapter 34. Storage
/dev/disk/by-path/ now accounts for NPIV paths
Previously, if two or more virtual host bus adapters (HBAs) were created on a single physical HBA, only a single link to the device was created in the
/dev/disk/by-path/ directory instead of one link for each path. As a consequence, creating a virsh pool with virtual HBAs by using Fibre Channel N_Port ID Virtualization (NPIV) did not work correctly. With this update, symbolic links in /dev/disk/by-path/ are created correctly and are unique. Symbolic links in /dev/disk/by-path/ created by udev for logical unit numbers (LUNs) connected through a physical Fibre Channel N_Port stay the same. (BZ#1266934)
When using thin-provisioning, buffered writes are no longer lost when the thin pool reaches capacity
Previously, a resize operation, even an automated one, attempted to flush outstanding I/O to the storage device prior to the resize being performed. Since there was no room in the thin pool, the I/O operations had to be errored first to allow the grow to succeed. As a consequence, if a thin-pool was filled to capacity, some writes could be lost even if the pool was being grown at that time. With this update, buffered writes are no longer lost to the thin-pool in the described situation. (BZ#1274676)
RAID migration now works correctly on the little-endian variant of IBM Power Systems
Previously, the
raid-migrate command failed on the little-endian variant of IBM Power Systems if the stripe size was not specified, as the iprconfig utility fell back on the current stripe size of the RAID and loaded it from the adapter without performing a proper endianness conversion The underlying source code has been modified to fix this bug, and RAID migration now works correctly on the little-endian variant of IBM Power Systems. (BZ#1297921)
The multipathd daemon no longer reinstates unusable Implicit ALUA ghost paths.
Previously, the
multipathd daemon automatically reinstated Implicit ALUA devices in the GHOST state, which were not usable. Multipath would continuously retry unusable devices, if they were the only ones present, instead of failing I/O operations. With this fix, multipathd no longer reinstates unusable Implicit ALUA ghost paths. As a result, multipath no longer continually retries I/O operations when only unusuable Implicit ALU A paths are available. (BZ#1291406)
Multipath now includes 0 sized standby paths in the multipath device
Some arrays do not report their size on the standby ports, resulting in 0 sized devices. Previously, Multipath did not allow 0 sized devices to be added to a multipath device. As a result, Multipath did not add 0 sized standby paths to the multipath device. With this update, Multipath now allows the addition of 0 sized paths to a device. (BZ#1356651)
Multipath no longers modifies devices with a dm table type of multipath that were created by other programs
Previously, the multipath tools assumed that they were in charge of managing all
dm devices with a multipath table. The multipathd daemon would modify the tables of devices that were not created by the multipath tools. With this update, the multipath tools now operate only on devices whose dm UUIDs start with mpath-, which is the UUID prefix that multipath uses on all the devices it creates. As a result, multipath will no longer modify devices with a dm table type of multipath that were created by other programs. (BZ#1241528)
The multipathd daemon now allows paths to be added to a new multipath device if it currently has no usable paths
Previously, when
multipathd created a new multipath device it did not allow any more paths to be added until it saw the udev change event for the multipath device being created, even if it created the device with no usable paths. If a multipath device was created with no usable paths, the udev device manager would hang trying to get information on the device, and until it timed out no active paths could be added to the device. With this fix, multipathd now allows paths to be added to a newly created multipath device if it currently has no usable paths. As a result, usable paths are immediately added to new devices that have none, and udev does not hang. (BZ#1350931, BZ#1351430)
The multipathd daemon no longer quits on encountering recoverable errors during startup
Perviously,
multipathd would quit instead recovering when it hit recoverable errors during startup. With this fix, multipathd now continues if it hits a recoverable error during startup and no longer quits. (BZ#1368501)
The multipathd daemon now responds to failed removes with fail rather than ok
Previously, the
multipathd daemon did not retain the error status when removing a path or a map failed and would respond to failed removes with ok. With this fix, multipathd now responds to failed removes with fail. (BZ#1272620)
Multipath no longer crashes when a uid_attribute is changed after a device is added and the device is then removed
Previously, if a path changed its WWID after being added to a multipath device, the
multipathd daemon would create a new device. This led to the path being in both devices. As a consequence, if users changed the uid_attribute after multipath devices were created and then removed the devices, multipathd would try to access freed memory and crash. With this fix, multipathd no longer allows the path's WWID to be changed while it is being used in a multipath device. As a result, multipathd no longer crashes in this scenario. (BZ#1323429)
Multipath no longer occasionally fails while renaming devices
Previously, multipath was using an uninitialized variable in the function to rename a device. This would cause multipath to fail occasionally while renaming a device because the variable was set to an invalid value. With this fix, multipath now initializes this variable when renaming a device. (BZ#1363830)
Systemd no longer reports that the multipath.pid file is not readable
Previously, systemd reported that it was unable to read the
multipathd.pid file after the multipathd command returned. This was because the multipathd command was returning as soon as it forked the daemon, and the daemon was not writing the pid file until after configuration was complete. With this fix, the multipathd command now either waits until the multipathd daemon has written the pid file or 3 seconds have passed before returning, and the daemon writes the pid file earlier in startup. As a result, systemd no longer reports that the multipath.pid file is not readable. (BZ#1253913)
Multipath now states that a path is not a valid argument for paths that do not belong to block devices
Previously, if you used a path to something that is not a valid block device, multipath would tell you that it
requires a path to check, which is unhelpful. This is because multipath considered anything that is not a block device path or major:minor number to be a multipath alias. With this fix, multipath will not treat fully qualified paths to anything that is not a block devices as a multipath alias. As a result, multipath will state the that path is not a valid argument for paths that do not belong to block devices. (BZ#1319853)
All /dev/mapper entries for multipath devices are now symbolic links created by udev
Previously, some
/dev/mapper entries for multipath devices were symbolic links (symlinks) and some were block devices since multipath was not correctly waiting for udev to create the /dev/mapper/ symlinks. With this fix, multipath now waits for udev after each transaction. As a result, all /dev/mapper entries for multipath devices are now symlinks created by udev. (BZ#1255885)
New devices are now claimed by multipath as soon as multipath creates a multipath device on top of them
Previously, the first time multipath saw a device, it was not claimed by multipath in the
udev rules since multipath will not claim a device in udev unless the the WWID is in the /etc/multipath/wwids file when processing the uevent. With this fix, when multipath adds a new device WWID to the wwids file, it will issue a change event on the device so it can claim it in the udev rules. New devices are now claimed by multipath as soon as multipath creates a multipath device on top of them. (BZ#1299600)
Failures on some devices no longer keep multipath from creating other devices
Previously, the
multipath command could fail to set up working devices because of failures on unrelated devices since it would quit early if it failed to get the information on any of the devices it was trying to create. With this fix, multipath no longer quits early if it fails to get information on some of the devices and failures on some devices no longer keep multipath from creating others. (BZ#1313324)
Multipath no longer misses uevent messages and it now adds all appropriate devices
Previously, multipath did not always adding all the path devices correctly because it was not correctly checking for the existence of a
libudev function to compile with support for resizing the uevent socket. Because of this, multipath was not resizing the uevent socket, and it could overflow. This caused multipath to miss necessary events. With this fix, multipath now checks for the proper libudev function and compiles with support for resizing the uevent socket. As a result, multipath no longer misses uevent messages, and it now adds all appropriate devices. (BZ#1296979)
The kpartx tool no longer returns before devices are created
Previously, by default the
kpartx tool returned without waiting for devices to be created. This was a source of confusion for users who would expect the devices to exist immediately after kpartx returned. With this update, kpartx by default now waits until the devices are created before returning. (BZ#1299648)
Multiple calls to resize a device will each attempt to resize the device, and will correctly report the result
Previously, if
multipathd failed to resize a device, it continued to think that the device had the new size. Subsequent calls to resize the device would report success and not resize the device because multipathd thought that it had nothing left to do. With this fix, multipathd now resets the device size to the original size if the resize fails. As a result, multiple calls to resize a device will each attempt to resize the device, and will correctly report the result. (BZ#1333492)
Multipath now correctly creates partition devices for 4k block devices with DOS partitions greater than 2TB
Previously, the
kpartx tool created the wrong size partitions for 4K block size devices with DOS partitions greater than 2TB. This was because kpartx stored the number of sectors and the multiplier needed to convert from the native sector size to 512B sectors in 32 bit unsigned integers. This causes a rollover if the two numbers multiplied together are larger than 2^32. with this fix, multipath now uses a 64 bit unsigned integer for the sector size multiplier variable, so the result will not roll over when the numbers are multiplied together. As a result, multipath now correctly creates the partitions. (BZ#1311463)
Multipath no longer removes partitions that are in use and restores partitions when a path is added back
Previously, if all paths to a device were lost, multipath would remove all the partitions that were not in use and never restore them. This occured because when multipath tried to remove a device it was removing partitions even if some of them were in use, and once they were removed it was never restoring them. With this fix, multipath now checks if any partition is in use before attempting a remove, and if the remove fails, it restores the partitions when a path is added back. (BZ#1292599)
The kpartx tool no longer overwrites an existing partition device when a new device's name matches the existing one
Previously, when a potential new device's name matched an existing device's name,
kpartx was silently overwriting the existing partition device with the new one. This would cause kpartx devices to suddenly change where they were pointing if there was a naming clash. With this fix, kpartx now checks the UUID to make sure that it is not overwriting a partition device that belongs to a different whole device. If there is a name clash, kpartx will now fail with an error message instead of changing where an existing partition device is pointing to. (BZ#1283750)
The mpathconf --allow command now creates a configuration file with the correct devices allowed for a node to boot
Previously, with certain setups the
mpathconf --allow command created a configuration file that did not allow the node to boot. This occurred because mpathconf --allow was removing existing entries from the blacklist_exceptions section of the configuration file, which could cause some of the allowed devices to be blacklisted. It also printed duplicate WWID entries in the blacklist_exceptions section. With this fix, mpathconf --allow no longer removes the existing blacklist_exceptions entries, and prints the WWID entries only once. This command now always creates a configuration file with the correct devices allowed for a node to boot. (BZ#1288660)
Multipath devices now get correctly identified as LVM physical volumes
Previously, LVM sometimes failed to recognize multipath PVs. This was because
multipathd could be reloading a device at the same time that the creation uevent for it arrived. The LVM udev rules do not allow processing a device that is currently suspended, which happens during a reload. With this fix, multipathd delays device reloads until after it has received the creation uevent. (BZ#1304687)
The multipathd daemon no longer prints that a path is up when it is actually down
Previously, the
multipathd daemon could print that a path was up when it actually was down. If multipathd detected that the path was down before it called the path checker, it never cleared the last path checker message and would print that out. With this fix, multipathd now clears the path checker message if the path is determined to be down before the checker is run. (BZ#1280524)
multipathd devices no longer fail to be created if udev is processing a partition device at the same time
Previously,
multipathd was unable to create a multipath device when udev had a lock on the path device. This was because multipathd grabbed an exclusive lock on the path devices while creating the multipath device and udev grabs a shared lock on the path devices while processing its partition devices. With this fix multipathd now grabs a shared lock as well, so that it can run at the same time as udev. (BZ#1347769)
systemd no longer prints warning messages about a missing dependency
Previously,
systemd printed warning messages about a missing dependency when The multipathd systemd service unit file required another unit file that was not available in the initramfs. With this fix, the multipathd unit file now uses Wants instead of Requires since it is able to operate without the blk-availability unit file. (BZ#1269293)
The kpartx generated devices now have the same partition number as the actual partition number
Previously, the
kpartx generated device partition number did not match with the actual partition number. This was because kpartx was not counting sun partitions with no sectors when determining the partition number. With this fix, kpartx now counts sun partitions with no sectors when determining the partition number and the kpartx generated devices now have the same partition number as the actual partition number. (BZ#1241774)
MTX no longer fails with large tape storage arrays
On systems configured with a large tape storage drive array, the MTX tool previously failed with an error. As a consequence, it was not possible to manage the tape storage. This update improves support for larger tape storage arrays, and MTX can now manage large tape storage as expected. (BZ#1298647)
Interferences between dmraid and other device-mapper subsystems no longer occur
Previously, the dmraid packages were compiled with an incorrect testing option. As a consequence, the
dmraid tool inadvertently scanned all devices, including any other device-mapper subsystems like LVM, which could interfere with those other subsystems and cause various failures while booting. With this update, testing mode is disabled in dmraid, and all devices are not scanned at boot. As a result, interferences between dmraid and other device-mapper subsystems no longer occur. (BZ#1348289)
systemd no longer warns about a missing unit for dmraid-activation.service after uninstalling dmraid
Prior to this update, the
/etc/systemd/system/sysinit.target.wants/dmraid-activation.service symbolic link was left on the system after uninstalling the dmraid packages, which caused the systemd service to warn about a missing unit for the dmraid-activation.service. With this update, the aforementioned symbolic link is removed when uninstalling dmraid. (BZ#1315644)
mdadm no longer fails to stop an IMSM RAID array during a reshape
Due to a bug, attempts to stop an Intel Matrix Storage Manager (IMSM) RAID array during a reshape previously failed. The underlying source code has been modified to fix this bug, and the
mdadm utility now stops the array correctly in the described situation. (BZ#1312837)
Using mdadm to assign a hot spare to a degraded array while running I/O operations no longer fails
Previously, assigning a hot spare to a degraded array while running I/O operations on the MD Array could fail, and the
mdadm utility returned error messages such as:
mdadm: /dev/md1 has failed so using --add cannot work and might destroy mdadm: data on /dev/sdd1. You should stop the array and re-assemble it
A patch has been applied to fix this bug, and adding a hot spare to a degraded array now completes as expected in the described situation. (BZ#1300579)
A degraded RAID1 array created with mdadm is no longer shown as inactive after rebooting
Previously, a degraded RAID1 array that was created using the
mdadm utility could be shown as an inactive RAID0 array after rebooting the system. With this update, the array is started correctly after the system is rebooted. (BZ#1290494)
Trying to reshape a RAID1 array containing a bitmap to a RAID0 array no longer corrupts the RAID1 array
Reshaping a RAID1 array containing a bitmap to a RAID0 array with the
mdadm utility is not supported. Previously, when attempting to reshape a RAID1 array containing a bitmap to a RAID0 array, the operation was denied, but the RAID1 array was corrupted. With this update the reshape is denied, but the RAID1 array stays functional as expected. (BZ#1174622)
A race condition no longer occurs with IMSM RAID arrays running an mdadm reshape operation
With Intel Matrix Storage Manager (IMSM) RAID arrays running an
mdadm reshape operation, a race condition could previously allow a second reshape to be launched on the same array before the first operation was completed, and the reshaping operation did not complete correctly. With this update, the race condition no longer occurs, and a second reshape operation cannot be started before the first operation is completed. (BZ#1347762)
mdadm can now assemble arrays that use device names over 15 characters long
Previously, the
mdadm utility could terminate unexpectedly with a segmentation fault when trying to assemble an array that included a device with a device name longer than 15 characters. With this update, mdadm assembles arrays correctly even when the arrays use device names longer than 15 characters. (BZ#1347749)
