From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 11 Sep 2001 13:57:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 11 Sep 2001 13:57:24 -0400 Received: from h24-64-71-161.cg.shawcable.net ([24.64.71.161]:20219 "EHLO webber.adilger.int") by vger.kernel.org with ESMTP id ; Tue, 11 Sep 2001 13:57:05 -0400 From: Andreas Dilger Date: Tue, 11 Sep 2001 11:57:13 -0600 To: Christoph Hellwig Cc: David Balazic , linux-kernel@vger.kernel.org Subject: Re: IBMs LVM ? Message-ID: <20010911115713.D29347@turbolinux.com> Mail-Followup-To: Christoph Hellwig , David Balazic , linux-kernel@vger.kernel.org In-Reply-To: <3B9E255C.8943D6BB@uni-mb.si> <200109111526.f8BFQLr25266@ns.caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200109111526.f8BFQLr25266@ns.caldera.de> User-Agent: Mutt/1.3.20i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sep 11, 2001 17:26 +0200, Christoph Hellwig wrote: > > I heard rumors about IBM porting their LVM code from AIX to Linux. > > IBM has an OpenSource volume manager called evms, and although > it does support AIX Volumes is has it's root in IBM's OS/2 > volume management system. (I believe someone at IBM thinks of PCs > when hearing Linux so all their ports start from OS/2...) 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