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

[Michael Marxmeier <mike@msede.com>]

-------- Original Message --------
Date: Wed, 05 Jan 2000 11:34:58 -0500
From: Brian Kress <kressb@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?

Brian


From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: First draft list of 2.3.x "Things to fix"
To: kparse@salem.k12.va.us ("David L. Parsley (lkml account)")
Date:   Wed, 5 Jan 2000 01:30:31 +0000 (GMT)
Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), linux-kernel@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
things
	1.	Not following the Coding Style
	2.	General poor readability - lots of complex loops, huge ioctl
functions

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.

Alan