Actually, this isn't quite correct. Yes, the EVMS folks started with
the LVM design from OS/2 (which was based on AIX LVM, but not compatible).
However, IBM DID GPL the AIX 4.3 LVM code, and there IS support for AIX
VGs under EVMS.
> > Will it be replaced with the one from IBM ?
>
> ALthough the current LVM has its's issues I hope not so - the current
> EVMS is the best example on hhow to not write kernel subsystems.
Do you have a specific complaint? The current LVM kernel code isn't all
that robust either (and the user-space code is not very pretty).
I DO think that EVMS will replace the current LVM code in the kernel. Why?
- It already has 100% compatibility with the current LVM on-disk layout.
- It already has 100% compatibility with AIX LVM code.
- It is already possible to do LVM autoconfig of volumes within the kernel
without needing an initrd to activate the volumes.
- It removes knowlege of partitions out of the disk drivers and makes them
a simple form of LV.
- It is already possible to use partial Linux-LVM volumes (i.e. use LVs
that are 100% available in a VG, even if a disk is bad/missing). You
can't do that with the current LVM (sometimes you can't even do it if
ALL of the disks are there).
- The AIX LVM on-disk metadata layout is FAR more robust than the current
LVM metadata layout. While this is supposed to be fixed for Linux-LVM
at some point, the previous Linux-LVM changes have been TERRIBLE with
respect to compatibility, while EVMS is DESIGNED to support multiple
on-disk metadata layouts.
- It is possible (not done yet) to add things like NT Logical Disk Manager
(NT LVM-stuff) into EVMS.
- It is possible (not done yet) to add HPUX LVM/veritas/OSF volume stuff.
- It is possible to merge MD RAID support into EVMS also, to support all
of the different RAID layouts with common code*.
All in all, instead of having things like striping/RAID-1/concatenation/
RAID-5 reimplemented in each subsystem (e.g. LDM/MD/veritas/etc) we can
take the current MD code and make it a layer in EVMS which can handle all
of these cases.
(*) While the exact on-disk layout of each RAID implementation may vary
slightly (block sizes, stripe widths, etc), I'm guessing that the majority
of it is common enough that we can re-use the existing MD code (parity
calculation, resync, etc) to handle most kinds of RAID-0/1/5 setups.
Cheers, Andreas
-- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert- 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/