[lkml]   [1999]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: from FIBMAP to FIONDEV
Matthew Wilcox wrote:
>> #define FIONDEV_UNSTABLE 2 /* location is temporary (e.g. scratch file,
> I think FIONDEV_VOLATILE would be a better name here.

Good idea.

> 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

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

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 /

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.054 / U:4.096 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site