[Top] [All Lists]

Re: LVM on Linux

To: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>, JFS Discussion List <jfs-discussion@xxxxxxxxxxxxx>
Subject: Re: LVM on Linux
From: Ric Tibbetts <ric@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 16 Jul 2001 13:52:00 -0700
References: <3B5349EA.7080900@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607
I should have specified in my original post:
The comments contained the the snippet of thread on this topic are not my own. The piece was taken directly from another conversation, between other individuals. I forwarded it along for the information of the folks here that were/are considering using LVM on their Linux boxes.
Beyond that, I claim no responsibilty for the content.

Ric Tibbetts wrote:

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
                 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
during the 2.5 cycle.

End Of Thread (tm).

<Prev in Thread] Current Thread [Next in Thread>