- Previously, removing a device from its container occasionally failed. With this update, mdadm attempts to remove such a device again.
mdadm --addcommand 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.
- 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.
- 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.
mdadm --monitorcommand 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.
- 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.
- 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.conffile 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
AUTOline in the
/etc/mdadm.conffile 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
- 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.
- The mdadm tool did not apply the
-1option when running the
mdadm --monitor --scan --oneshotcommand or its short equivalent. Consequenlty, mdadm was monitoring the respective device continuously. With this update, the underlying code has been modified and the
--oneshotoption is applied as expected.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
idle. Consequently, the
mdmondaemon 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
Normalstate in OROM and the rebuild seemed to be finished. However, the RAID volume was in the
auto-read-onlystate, metadata was in the
Dirtystate, 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
idle, it checks if the rebuild process has really finished.
- 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.
--size maxoption 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.