Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > o EVMS (Enterprise Volume Management System) (EVMS team)
>
> or LVM2, which already appears to be scrubbed down and clean
Is there any reason why not both can go in? As far as I know neither
of them needs much of core changes, they are more like independent "drivers"
of the generic block layer stacking interface. There are already multiple
drivers of this - LVM and the various MD personalities.
One disadvantage of the LVM2 concept is that it relies a lot on compatible
user space and there is unlikely to be a stable API. While I'm normally
all for putting things in user space where it makes sense I think the
mounting of your root file system is a bit of exception.
I used LVM1 for some brief period and managing the different incompatible
user space tools if you wanted to boot different kernels with different
incompatible user space tool versions in parallel for development was
just hell. I don't see LVM2 being much better here - as soon as you want
to run more than a single kernel version you will likely run into problems
with the user space tool versioning.
With EVMS' concept of having more stuff in kernel space (especially the
initial recovery) it looks much more likely that one can keep using it
over multiple kernel versions with minimal hazzle.
Of course LVM2 is still the much elegant design, but at least for some
use cases (like mine) I see space for EVMS.
But then they are essentially device drivers anyways. No reason why not
both can be merged.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:34 EST