Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Andi Kleen <ak@suse.de>]

On Sun, Jul 21, 2002 at 02:40:11PM +0100, Alan Cox wrote:
> On Sun, 2002-07-21 at 07:57, Andi Kleen wrote:
> > 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. 
> 
> LVM2 relies on people doing things right so we shouldnt use it ? 

The problem in my opinion with LVM2 is that the design makes it 
near impossible to get a stable ABI between user and kernel space
(at least if you don't want to freeze it completely). User space
and kernel space are deeply tangled together and there is no
abstraction layer

And after my LVM1 experiences I am not going to give my root filesystem
to anything that is not committed to a stable ABI between all 
stable and development kernels.

To give one example: at one point I had 
/lvmtools1/vgchange -a y || /lvmtools2/vgchange -a y || /lvmtools3/vgchange -a y
in an startup script just to handle booting of different kernel versions
with differnet incompatible LVM ABIs on the same system. 
As far as I can see this problem is not addressed in LVM2 and its design
makes it even harder to address than it was in LVM1

Then of course there are people who only ever use a single kernel
version and for them this is no issue and I guess for them LVM2 will
be fine. But for the others EVMS looks like a better alternative.

But as I said in my earlier mail there is really no reason to chose 
on over another. They do not impact any core code and both can be put in.

-Andi