5.188. mdadm

Bug Fixes

BZ#771332

Previously, removing a device from its container occasionally failed. With this update, mdadm attempts to remove such a device again.

BZ#808776

The mdadm --add command could fail when adding to an array a device similar to a recent member of the array. With this update, the code restricting device addition has been corrected to only apply to members of recent arrays which have failed and require manual assembly.

BZ#811282

It was not possible to add a write-intent bitmap to a multiple-device (MD) array built with the metadata version property 1.0. This happened because mdadm occasionally failed to calculate the bitmap location correctly. With this update, a write-intent bitmap can be added to such an MD array as expected.

BZ#730052

If the user rebooted the system during a reshape process, MD RAID devices could remain inactive due to several problems. This update introduces several patches adjusting the logic of the reshape process and fixing several errors.

BZ#808424

The mdadm --monitor command terminated unexpectedly after completing a resynchronization process due to buffer overflowing. This happened when there were more than 40 mismatches reported during the resync process as the respective buffer could hold only 40 mismatch reports. With this update, the buffer has been enlarged and can now hold up to 80 mismatch reports.

BZ#790394

The mdadm tool could fail to add a device to a degraded array with bitmaps and exited silently. This happened because the called functions attempted to write to not-aligned buffers. With this update, an upstream patch to fix this bug has been applied: the patch modifies the underlying functions to use their own aligned buffers and the problem no longer occurs.

BZ#788022

If the user installed Red Hat Enterprise Linux 6.0 on a machine with a version 0.90 MD RAID array already installed, the array did not automatically start at the next reboot. This happened because the policy statement in the /etc/mdadm.conf file excluded automatic startup of version 0.90 RAID arrays (however, if such an array was needed on boot, dracut did start this array). The user could add +0.90 to the AUTO line in the /etc/mdadm.conf file to have such RAID arrays come up on boot.

In Red Hat Enterprise Linux 6.1 and 6.2, mdadm always assembled version 0.90 RAID arrays automatically due to a bug. This update fixes the bug. The user needs to implement the same fix as described above for Red Hat Enterprise Linux 6.0 to have version 0.90 RAID arrays come up on boot (add +0.90 to the AUTO line in /etc/mdadm.conf).

BZ#808438

The mdadm utility did not check how many volumes per controller were allowed for arrays on Intel controllers with OROM (Option ROM) or EFI (Extensible Firmware Interface) created by IMSM (Intel Matrix Storage Manager). Consequently, only the respective limited number of arrays were available even if further arrays were previously added. With this update, mdadm checks OROM limitations and adding a new volume is blocked if the number of volumes on the device attached to the given controller has exceeded the limit.

BZ#771554

The mdadm tool did not apply the --oneshot/-1 option when running the mdadm --monitor --scan --oneshot command or its short equivalent. Consequenlty, mdadm was monitoring the respective device continuously. With this update, the underlying code has been modified and the --oneshot option is applied as expected.

BZ#808492

IMSM RAID only supports two volumes per container. Previously, mdadm allowed an administrator to create the second volume smaller than the remaining free space leaving unallocated space in the container. With this update, the second volume must take up the remaining space of the container by applying the same restrictions as when managing the IMSM RAID throught the BIOS interface.

BZ#808507

Disk and volume sizes were stored as metadata in 32-bit blocks. If the disk size exceeded 2 TB, the allocated space was no longer sufficient to store the size value and volume sizes returned incorrect results for such disks. With this update, the size of the block is calculated depending on the disk or volume size, and, in the scenario described, the correct disk and volume sizes are used and displayed.

BZ#808519

The mdadm tool failed to create a link to the IMSM container device during incremental assembly. This happened when the device metadata did not provide a name for the container. With this update, if no container name has been provided, the metadata version name is used as the container name and a digit is added to the end of the container name so that the link to the IMSM container device is created correctly.

BZ#754998

When an array reshape process was restarted during array assembly, the file system placed on the array could not be mounted and the system returned a busy error. This happened because the child process of the reshape that handled the external metadata of the array was not closed on restart and a memory leak occurred. Consequently, the metadata update failed. With this update, the underlying code has been changed so that the child process of the reshape process is closed under these circumstances and the problem no longer occurs.

BZ#754986

When migrating a non-RAID system to a RAID5 system, an excessive amount of memory could be consumed and the migration process could fail due to a memory leak. With this update, the underlying code has been modified so that the respective resources are freed and the problem no longer occurs.

BZ#812001

If a system containing IMSM RAID devices was rebooted during the rebuild of the IMSM RAID devices, the MD driver changed the device sync_action status from recover to idle. Consequently, the mdmon daemon could detect this change, finish the rebuild process, and write the metadata of the unfinished rebuild process to disks before the restart. After restart, the RAID volume was in the Normal state in OROM and the rebuild seemed to be finished. However, the RAID volume was in the auto-read-only state, metadata was in the Dirty state, and the data was inconsistent (out-of-sync). With this update, the appropriate test has been added and, when mdmon now detects the change of sync_action from recover to idle, it checks if the rebuild process has really finished.

BZ#814743

An entry could be missing in the device map file if an entry for an array with the same name existed in the device map file. This update fixes the problem so the entry is added to the device map file in such cases.

Enhancement

BZ#808475

The --size max option has been added, allowing the administrator of an IMSM array to enlarge the last volume in the array to take up the remaining space in the array.