Right now, 42 bytes. And you already need 64 just to store the location
of a backup sector for each sector that's there ...
> So do you approve of the idea of adding an index to the call to allow the
> application to find out about all possible real blocks which contain
> this data?
I'm not sure about it. On the one hand, this type of basic replication
is just what the interface could handle properly. On the other hand,
all other cases are already too complex, because you'd actually need
a set of locations, plus an algorithm. RAID can easily be extended to
quite arbitrarily complex structures, so even a simple table of known
algorithms may not be sufficient. Also, once you have the information,
what are you supposed to do with it ?
One could incrementally load the boot loader, i.e. first stage with
capabilities to load and correct one additional sector, second stage
with the capability to load a sector with a list of sectors, using
code already brought in by the first stage, then second stage loads
the third stage, with user interactions, etc.
But this gets very complex and it still doesn't solve the problem of
actually identifying the valid set of information, which may simply be
impossible for the first stage. (Asking the user is also a problem
at this point.)
Maybe somebody working on RAID could explain what is involved in
detecting the status of a set of volumes ?
Unless there's a useful solution for this, I don't think it makes
much sense to construct a complex solution that still doesn't handle
maybe 50% of all cases.
- 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/