On Tue, 2009-04-28 at 16:20 -0700, H. Peter Anvin wrote: > Neil Brown wrote: > > > > That only leaves the question of what happens when a spare is added to > > the array - how does the grub data get written to the space on the > > spare. > > I would rather that grub were responsible for this, than for md to > > treat that unused space as RAID1. > > We already have a notification system based on "mdadm --monitor" to > > process events. We could possibly plug grub in to that somehow so > > that it gets told to re-write all it's special blocks every time > > something significant changes in the array. > > > > I have multiple issues with this concept (including promoting Grub2, but > let's not get into that.) > It could be a call to a generic interface for reinstalling the bootloader. It's not intended to be grub specific, it just so happens that grub2 is the closest to having a working boot from software raid implementation. > For this to be reliable, there is only one sensible configuration, which > is for /boot to be a RAID-1, which is better handled by -- guess what -- > partitioning systems; and we already have quite a few of those that work > just fine, thank you. Otherwise there WILL be configurations -- caused > by controller failures if nothing else -- that simply will not boot even > though the system is otherwise functional. Promoting this kind of stuff > is criminally stupid. I disagree. Grub is quite capable of booting from and assembling a raid5 volume and accessing it's partitions contents, even if the array is degraded. All I'm asking for is that the first 64 kbytes of the disk be reserved and some of it possibly (but not necessarily) replicated so that a bootloader capable of assembling a raid array can be installed on the start of each member disk so that whatever disk the bios decides to boot from, it will always boot. -- Daniel Reurich Centurion Computer Technology (2005) Ltd Ph 021 797 722 -- 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
