[linux-lvm] FW: LVM on Linux

Tue Jul 17 11:27:27 UTC 2001

On Mon, Jul 16, 2001 at 03:35:35PM -0500, Gonyou, Austin wrote:
> >From the XFS list. 
> 

Austin,
I stated to Ben's unserious mail you included at the end below but didn't get a
serious asnwer back so far :-(

Don't get me wrong: I really appreciate to get reasonable proposals.

Regards,
Heinz    -- The LVM Guy --

On Thu, Jul 05, 2001 at 03:35:31AM -0400, Ben LaHaise wrote:
> On Thu, 5 Jul 2001, Ragnar Kjørstad wrote:
> 
> > What do you mean?
> > Is it not feasible to fix this in LVM as well, or do you just not know
> > what needs to be done to LVM?
> 
> 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,

What is the particular problem with 1?
Changes need to take place in the whole block device layer during 2.5
development in order to be 64 bit clean.

LVM will just be one member of the bunch :-)

> 2) never used multiplication,
> division or modulus on block numbers,

I assume that you mean an advice ("never use") rather than a statement
that you never used it, right?

FYI: this takes place in multiple block device layer functions.

For sure you can argue that this is supposed to vanish in 2.5 but
were's the document recommending this and defining how to do it?

> and 3) don't allocate memory
> structures that are indexed by block numbers.

Why?

Remapping block devices do that!
Checks against index mismatches are in LVM already.

> Even 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.

Sorry but you are argueing weakly in a political manor.

Please speak up clearly and talk about the caveats you see and change request
you recommend as an expert or say nothing!

> It will continue
> to work on 32 bit block devices, but if you try to use it beyond that, it
> will fail.

As I said above.
During the 2.5 development cycle it will be addressed.

> 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.

Once 64 bit support will be implemented in the block device layer
and the VFS, LVM as a block device layer entity will support it as well :-)

> 
> Now, thankfully there are alternatives like ELVM, which are working on
> getting the details right from the lessons learned.

ELVM is not in production so far...
If you would have read the EVMS kernel code, you had realized that they do
modulo calculations as well and I think they are doing right!

> Given that, I think
> we'll be in good shape during the 2.5 cycle.

I agree (from a different standpoint though ;-)

Waiting for your serious advice...

> 
> 		-ben
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin at coremetrics.com 
> 
> > -----Original Message-----
> > From: Ric Tibbetts [mailto:ric at pipcws.ca.boeing.com]
> > Sent: Monday, July 16, 2001 3:09 PM
> > To: Linux XFS Mailing List; JFS Discussion List
> > Subject: LVM on Linux
> > 
> > 
> > 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).
> > 
> > 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen at Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-