lkml.org 
[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RFC: from FIBMAP to FIONDEV
Date
Matthew Wilcox wrote:
> Okay, I accept that there's probably no sensible way for LILO to deal
> with RAID-[2345] right now. However, that doesn't mean we should design
> an interface that can't support it in a sensible way. To me that means
> we should have an index count passed to FIONDEV.

I agree that far. I'm not entirely sure if the number of channels/
stripes/slices/whatever should have to be discovered iteratively (e.g.
increment index until FIONDEV_COPIES is no longer set), or if we
should have a field for the total number.

> RAID 2,3,4,5 return the data block on the first call and set the
> COPIES flag. Subsequent calls set the XOR flag to indicate that the
> other blocks should be XORed together to recover the original block.
> lilo is perfectly free to ignore this information, but maybe someday
> we'll have a good way to use this information.

As I've said before, I'm sceptical about assuming that we have either
straight mirroring over M drives or XOR over N drives. E.g. you could
have a mixture of both, or you could even use a system where you can
recover from the loss of more than a single drive.

So a single bit (FIONDEV_XOR) is unlikely to be sufficient. But we
could probably get away with an algorithm index, although it may
become ugly for more complex cases:

0 reserved; description of redundancy structure is unavailable
1 mirroring; all available indices refer to a direct copy
2 XOR; the last available channel contains an XOR of the others

Then FIONDEV_COPIES implies that additional information is available
in the algorithm index field. Maybe its name should then be changed to
FIONDEV_STRUCTURED or such. The algorithm field stays constant for all
accesses to the same location. Also, only mapping the last location
will advance the current file position.

Gets a bit complex :-(

> With RAID 1, lilo can install multiple copies of LILO, one on each disc,
> each one told about the blocks which exist on its own disc.

Well, technically it could, because it happens to know where the data
goes. However, this would involve allocating space in the RAID, via
the file system, and then filling it via direct writes to the underlying
devices. Pretty horrible, if you ask me.

No, as far as LILO is concerned, I consider this a case of policy at a
higher level. LILO just writes a single boot loader in a well-defined,
clean way. If there's replication in the RAID, you install multiple
boot loaders, and you tell LILO explicitly where they go.

- Werner

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.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/

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