Tobias Powalowski wrote:
Hi guys,
while experimenting with different raid setups in kvm, i found out our raid
support is not really ideal.
The status now:
- raid hook(inlcuded in mkinitcpio package) does assemble normal raid:
but if a drive fails it will fail to boot after it.
i'm not 100% sure if it can handle all types of raid levels, partitionable
mdp raid doesn't work at all with this hook for sure.
- raid-partitions(included in mdadm package) can only assemble 1 raid
partition array, which is imho bad you should be able to assemble more than
one raid partition device from commandline, if you wish to do so.
- UUID is not supported in any of both.
A few notes, as I have mentioned it a few times in the past year(s)
regarding the hooks you use. Why to rely on kernel commandline and
in-kernel detection ? This is kinda legacy and deprecated (as far as I
know) approach. IIRC in-kernel assembly also has problems with 1.x md
superblocks, recalling mailing list - but I'm not sure as I never really
use kernel assembly.
Having initramfs generator like mkinitcpio, just make sure proper
/etc/mdadm.conf is included into generated image through install part of
the hook.
In most systems I use, I have root on lvm on raid. Regardless of what is
used for initramfs image, the part responsible for md basically requires
module loading (if necessary) and mdadm -As. Mdadm doesn't need any
manual device nodes creation, neither does mdassemble.auto. Udev rules
in the background do the rest, so one can have e.g.
root=/dev/disk/by-..... should it be needed.
I described the general idea in http://bugs.archlinux.org/task/9122
It also tries to dynamically create mdadm.conf in case one doesn't exist
(going from mdadm -Es, instead of parsing kernel commandline). And it
detects required modules as well.
Also, as of current kernel and mdadm, each md raid is partitionable by
default. Old naming scheme for partitionable raids remained for
backwards compatibility.
Remarks, as the above is already 1+ year old:
Device access is still needed to trigger partition uevents. Future mdadm
(3.x) will work with udev properly, recalling long discussion about it
on linux-raid. Some of the simple changes to udev ruels I suggested made
it into upstream as well. Most generic one (including scanner helper for
custom raid names and etc., not mentioned in the above bugreport)
didn't, being too hackish. Still - simple naming, once you decide on
single arch preferred standard is pretty trivial without any external
helpers.
The only "drawback" is having libc or static mdadm / mdassemble.auto in
the image Unless someone is trying to boot Arch on machine with
incredibly low amount of ram (even for P2 ages), this is hardly any problem.
On a related note - arch's udev rules (81-...) still have entry for md,
which should likely be removed, as 64-... takes care of it. Current udev
also allow overriding NAME in further rules, should that matter for arch.
FYI. Sorry for crossposting, no other way though :)
