Message-Id: <3B5349EA.7080900@pipcws.ca.boeing.com>
Date: Mon, 16 Jul 2001 13:09:14 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607
MIME-Version: 1.0
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>,
   JFS Discussion List <jfs-discussion@oss.lotus.com>
Subject: LVM on Linux
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

For anyone considering using LVM on Linux. You might want to take a 
second to look at the following "short" article. It casts a 
questionalble light on the current state of the LVM code.

================================================

0 Jun - 5 Jul (8 posts) Archive Link: [RFC][PATCH] first cut 64 bit block
support
                  Summary by Zack Brown

Ben LaHaise posted a patch and announced, "Below is the first cut at making
the block size limit configurable to 64 bits on x86, as well as always 64
bits on 64 bit machines. The audit isn't complete yet, but a good chunk of
it is done." [..] "The following should be 64 bit clean now: nbd, loop,
raid0, raid1, raid5." He gave links to two homepages at
http://people.redhat.com/bcrl/lb/ and
http://www.kvack.org/~blah/lb/. He added, "Ugly bits: I had to add libgcc.a
to satisfy the need for 64 bit division. Yeah, it sucks, but RAID needs some
more massaging before I can remove the 64 bit division completely. This will
be fixed." Chris Wedgwood proposed some changes to libgcc.a to be less ugly,
and Ben replied, "I'm getting rid of the need for libgcc entirely. That's
what "This will be fixed" means. If you want to expedite the process, send a
patch. Until then, this is Good Enough for testing purposes."

Elsewhere, Ragnar Kjarstad was very happy about Ben's work, asking if LVM
was also 64-bit clean. Ben replied cryptically, "Errr, I'll refrain from
talking about LVM." Ragnar wanted some clarification, and Ben explained:

Fixing LVM is not on the radar of my priorities. The code is sorely in need
of a
rewrite and violates several of the basic planning tenents that any good
code in the block layer should follow. Namely, it should have 1) planned on
supporting 64 bit offsets, 2) never used multiplication, division or modulus
on block numbers, and 3) don't allocate memory structures that are indexed
by block numbers. LVM failed on all three of these -- and this si just what
I noticed in a quick 5 minute glance through the code. Sorry, but LVM is
obsolete by design. It will continue to work on 32 bit block devices, but if
you try to use it beyond that, it will fail. That said, we'll have to make
sure these failures are graceful and occur prior to the user having a chance
at loosing any data.

Now, thankfully there are alternatives like ELVM, which are working on
getting the
details right from the lessons learned. Given that, I think we'll be in good
shape
during the 2.5 cycle.

End Of Thread (tm).