ReliableRaid
|
Size: 4099
Comment:
|
Size: 4161
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 19: | Line 19: |
| * mdadm still reads/depends on a static /etc/mdadm/mdadm.conf file containing UUIDs (in the initramfs !!!). It refuses to assemble any other array hotpluged into the system correctly but stets up non working /dev/md_d? arrays. (It does not just go assembling matching superblocks and run arrays (only) if they are complete.) This actually breaks the autodetection setup of every array newly created on a system as well as pluging in a (complete) md arrays from another system. Bug:252345 For updating that initramfs refer to: http://ubuntuforums.org/showthread.php?p=8407182 | * mdadm still reads/depends on a static /etc/mdadm/mdadm.conf file containing UUIDs (in the initramfs !!!). It refuses to assemble any hotpluged array not mentioned and taged with the own hostname. (It does not default to just go assembling matching superblocks and run arrays (only) if they are complete.) This behaviour actually breaks the autodetection of every array newly created on a system, as well as pluging in a (complete) md arrays from another system. Bug:252345 For updating that initramfs refer to: http://ubuntuforums.org/showthread.php?p=8407182 * Ubuntu does not make use of partitionable (/dev/md_dX type) arrays. |
RAIDs (Redundant arrays of independent disks) allow systems to keep functioning even if some parts fail. With hardware raids you just plug more then one disk side by side. And if a disk fails a buzzer or email watchdog will notify you that you have to plug a new (spare) disk to up the redundancy again.
Unfortunately ubuntu's md (software) raid configuration seems to suffer from a little incompleteness.
The assembling of arrays with "mdadm" has been moved to the hotplug system (udev rules).
However:
The proper mdadm --incremental option does not work in initramfs (not creating device nodes) 251663
The proper command (i.e. for boot scripts) to start only selected hotplugable raids degraded (i.e. the rootfs after a timeout from initramfs) is not available. 251646
The corresponding command "mdadm --incremental --scan --run" to start all remaining hotplugable raids degraded (something to execute only manually) does not start anything. 244808
- Using the legacy method to start an array degraded will break later --incremental (re)additions from udev/hotplugging.
mdadm still reads/depends on a static /etc/mdadm/mdadm.conf file containing UUIDs (in the initramfs !!!). It refuses to assemble any hotpluged array not mentioned and taged with the own hostname. (It does not default to just go assembling matching superblocks and run arrays (only) if they are complete.) This behaviour actually breaks the autodetection of every array newly created on a system, as well as pluging in a (complete) md arrays from another system. 252345 For updating that initramfs refer to: http://ubuntuforums.org/showthread.php?p=8407182
- Ubuntu does not make use of partitionable (/dev/md_dX type) arrays.
- The initramfs boot process is not (a state machine) capable of assembling the base system from devices appearing in any order and starting necessary raids degraded if they are not complete after some time.
251164 boot impossible due to missing initramfs failure hook integration
136252 mdadm, initramfs missing ARRAY lines
247153 encrypted root initialisation races/fails on hotplug devices (does not wait)
488317 installed system fails to boot with degraded raid holding cryptdisk
491463 upstart init within initramfs
For degraded regular (non-rootfs) arrays there is no init script at all to start/run them degraded. 259145 non-root raids fail to run degraded on boot
- The ubuntu server manual says and claims that "If the array has become degraded, due to the chance of data corruption, by default Ubuntu Server Edition will boot to initramfs after thirty seconds. Once the initramfs has booted there is a fifteen second prompt giving you the option to go ahead and boot the system, or attempt manual recover." However,...
- The kernel will never autostart a raid that is not reproducing a correct checksum, no matter if degraded or not. There is nothing to manualy recover about a degraded raid before it can be started. A recovery console is appropiate *after* starting a raid degraded has failed.
- A replacement disk can be added at any time if a spare disk isn't already installed from the beginning. If the disks are not connected over a hotplugable interface, the system must be powered down for this. (Recovery console is also pointless here.)
If a drive fails while the system is powered up, by default nobody is notified and the system will simply reboot degraded afterwards anyway. Reason: 244810 inconsistency with the --no-degraded option.
- The boot process will usually not be stopped (and should not) for something (like adding and syncing a new drive to the raid) that is designed to be done on live systems (quite a good thing to do as default).
- (There is actually no need or reason for a failed drive to prevent a redundantly constructed system from booting. The Bugs on this page are causing this. There might be a good reason to automatically setting up raid systems with mdadm --monitor to notify-send/email to users/admins of the system if a drive has failed, instead.)
ReliableRaid (last edited 2015-01-28 01:12:46 by penalvch)