Subject: Re: Current state of Logical Volumes in NetBSD
To: Alistair Crooks <firstname.lastname@example.org>
From: Adam Hamsik <email@example.com>
Date: 11/25/2007 14:40:18
On Nov,Sunday 25 2007, at 12:34 PM, Alistair Crooks wrote:
> On Sun, Nov 11, 2007 at 10:17:57PM +0100, Adam Hamsik wrote:
>> On Nov,Sunday 11 2007, at 12:36 PM, Alistair Crooks wrote:
>>> On Sun, Nov 11, 2007 at 11:35:45AM +0100, Markus Kolb wrote:
>>> I don't want to try to speak for mycroft, but my understanding of
>>> his idea of wedges was that they are just simple things, which use
>>> the strategy functionality to route requests to different areas
>>> on the block device(s). Something crafted on top of this could
>>> a nice, light volume manager.
>> Yes, that's absolutely true. NetBSD wedges provides linear disk
>> mapping same as Linux md. IMO it should be not so hard to write
>> volume manager for NetBSD on top of wedges. There are 3-4 options how
>> to do it:
>> 1)use this years SOC code from ZFS port. I don't know if this code is
>> in useable state.
>> if not it would be good give more effort at this.
>> 2)port Linux libdevmapper and lvm2 tools to netbsd on top of our
>> wedges with some support. I think that this way we keep GPL out of
>> kernel and we can use IMO really good linux lvm NetBSD volume
>> Intro to Linux Lvm internals .
>> 3) write tools + wedge device library from scratch
>> I prefer 2 because of
>> a) well tested code
>> b) was already done 
>> c) I think that linux LVM is better than nothing.
> Thanks for the pointers.
> I wholeheartedly agree with the benefits drawn here.
>> a) add GPL stuff to netbsd base system :(
>> b) too much people here hate Linux and Linux stuff :).
> I disagree that too many people "hate" Linux. But some of the sources
> that are mentioned are LGPL, not GPL.
> But on to the meat of this mail:
> Looking at reference  that you gave below (I missed that one, I was
> on holiday at the time), I managed to get a kindly NetBSD developer to
> forward me through the sources that Christian Limpach provided
> pointers to. I've brought the devmapper package up to date, and also
> the lvm2 one (latest sources from sourceware.org). Michael van Elst
> fixed an issue with the PLIST in the lvm2. I've added Christian's
> lvm.c and lvmvar.h files in the files/ subdirectory of the lvm2
Thats excellent news. I have tried that old links and they didn't work.
> I've put them up on
> I'm not wedded to the idea of having these as packages, it's just the
> vehicle that they came in, and because I'm fairly cognisant of the way
> packages work.
Yes if it is possible we should integrate lvmtools into the base.
> I haven't tried these yet, beyond verifying that they run far enough
> to complain about a non-existent directory under /var. I haven't
> tried to build a kernel with Christian's lvm driver in there either.
> What I would say is that most of the leg work to provide logical
> volume management in NetBSD has been done, and it just needs a little
> finishing off. And that's where someone else (TM) comes in, because
> hardware constrained at the moment (even virtual hardware).
I will do that. I will have some free time in Tuesday and I will look
> If someone would like to take these and run with them, please do - I'd
> be delighted to have volume management in NetBSD.
> Hope all this is useful - any questions, please let me know.