[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: from FIBMAP to FIONDEV
    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 /

    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.036 / U:6.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site