Messages in this thread | | | From | Werner Almesberger <> | Subject | Re: RFC: from FIBMAP to FIONDEV | Date | Tue, 15 Jun 1999 18:22:57 +0200 (MET DST) |
| |
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/
| |