Good idea.
>> FIONDEV_COPIES
[...]
> I wonder if this is good enough. What do you think to the idea of having
> an index passed to the routine (initially set to zero) which could be
> incremented to find all copies of this block? This takes care of RAID-1
> and RAID 0+1.
I'm not so sure what to do about RAIDs. In many cases, the boot loader
wouldn't even know if something is wrong. (And, fortunately, in most
cases, it shouldn't be affected either.) With more complex RAIDs,
reconstruction is non-trivial, and in addition you need to know what
RAID mode you're in, etc.
Furthermore, there's not enough space in the first stage to do anything
with RAIDs anyway. So you'll end up with only a partial recovery
capability.
So a useful solution would be more along the lines of creating two or
more similar but not identical installations of LILO and to have some
means to switch between them. For maximum reliability, you probably
want your BIOS to decide which disk is okay, and boot that one.
Now all this is beyond FIONDEV, because you either need to go to the
"real" partitions or you need to have some means to select one of the
redundant "forks" - not only for FIONDEV, but also for reading and
writing.
So in terms of complexity, the best approach is probably to create
two or more small "normal" partitions on sufficiently different
drives, and to install LILO, the kernel(s), etc. on each of them.
Then add whatever is necessary to pick the right one for booting.
Note that recovery from disk corruption due to an unclean shutdown
isn't a likely cause of problems, because you're not supposed to
boot new kernels that frequently on your high availability system in
the first place ;-)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-ICA,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/