On 30 Jun 2009, at 18:54, Goswin von Brederlow wrote:
In case of grub2: It does support both raid and lvm. The raid superblocks are parsed to construct mdX devices and the lvm metadata is parsed to locate lvm logical volumes. So you could say it does construct the LV and mounts the FS.
Interesting, thanks. I've not been following grub2 development. Given the production nature of these systems though (and the customer) I'm stuck with grub legacy until Redhat update it and support grub2, which judging from the chatter on the Fedora Project Portal about the possibility of including it in Fedora 12, could be some years off. Looks like Ubuntu will be putting it into 9.10 though, so I'll have a play with it on one of my dev boxes at home.
In case of lilo: Lilo only stores a list of blocks where the kernel/initrd are on the device. Afaik each component device of a raid stores the the block numbers for the kernel/initrd on that component device. So no matter which component device boots it will find the kernel/initrd on the same device. The raid1 and lvm are completly circumvented.
Have not touched lilo since grub went main stream, but will have another look at that.
I've gone over all this with the customer. They want belt and braces protection (they are to be very critical systems in a hospital) so we've decided to hardware mirror c0d0 and c0d1 for the disks on one controller, plus the same for c1d0 and c1d1 on the second controller, then partition and md mirror both of those. The rest of the disks will be handled separately and the kickstart config is quite simple. It's a bit overkill, but it won't be failing disks or controllers that cause the systems to fail in the future.
Rgds, John -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
