[linux-lvm] [Fwd: First draft list of 2.3.x "Things to fix"] (fwd)

Michael Marxmeier mike at msede.com
Wed Jan 5 20:01:54 UTC 2000

-------- Original Message --------
Date: Wed, 05 Jan 2000 11:34:58 -0500
From: Brian Kress <kressb at moose.net>
Subject: [Fwd: First draft list of 2.3.x "Things to fix"]

Hi all,

	This was posted to linux-kernel by Alan.  This
is interesting, because I haven't seen anything before
about this barrier to LVM being included in 2.3.  Is there
any chance to get the formatting fixed in 0.8?


From: Alan Cox <alan at lxorguk.ukuu.org.uk>
Subject: Re: First draft list of 2.3.x "Things to fix"
To: kparse at salem.k12.va.us ("David L. Parsley (lkml account)")
Date:   Wed, 5 Jan 2000 01:30:31 +0000 (GMT)
Cc: alan at lxorguk.ukuu.org.uk (Alan Cox), linux-kernel at vger.rutgers.edu

> including mine.  With the proliferation of ext2 resizing tools, this sure
> would be sweet; LVM could have saved my butt a few times in the last few
> years.
> Any numbers on the "minimal" performance loss of the extra layer?

When I tried it for a bit in 2.2.x-ac I couldnt measure any. 

The reason I gave up adding it to -ac was that I cleaned it up , I
fixed it for the
Coding Style document and I fixed some bugs. I got an update from the
author that simply
ignored all that work and reverted to wrong formats. 

Every annoyance I personally have with the LVM code comes down to two
	1.	Not following the Coding Style
	2.	General poor readability - lots of complex loops, huge ioctl

The main thing it made me wonder was if the ioctl interface layer was
perhaps structured
badly and perhaps using different ways to pass the data would avoid a
lot of the mess
in the existing code.

The actual remapping code is fast, clean and works. It also has about
zero impact if the
LVM is disabled.


More information about the linux-lvm mailing list