Subject: Re: iSCSI, lvm, storage and the future
To: Alistair Crooks <firstname.lastname@example.org>
From: Adam Hamsik <email@example.com>
Date: 12/09/2007 01:06:29
On Dec,Saturday 8 2007, at 3:45 PM, Alistair Crooks wrote:
> Hi guys,
> I've been talking to various people about storage and NetBSD, and I
> think we're way out in front of all the rest of the open source
> So I'd like to make a big thing of our storage story, of what we have
> now, and where we're going with it. So I'm going to do a storage
> for NetBSD, and put that up on the website.
> This won't have dates beside it, for obvious reasons, but I expect
> start looking at branching 5.0 sometime in February/March, and so
> as many components of the storage side of NetBSD in place by then
> be good.
> So my take on various elements is as follows:
> 1. iSCSI - there, running, we have initiator and target. target needs
> dynamic management, initiator needs boot support. Snapshot support
> in target will be there RSN. RAID1 rebuild, hot swap addition and
> need to be done.
Also raid5 resize would be good.
> 2. To manage these, we need LVM - the Lunix one would seem to be the
> best option. Adam - how is this work going? If you want others to work
> on parts of it, please let me know. If you need a cvs repo, let me
> we can use one of mine - I have a setup in New York at Panix, and one
> at home here in the UK, I can let you have commit access to either.
I have tested old lvm kernel code and it is not compatible with new
libdevmapper nad lvm2tools. libdevmapper and device-mapper device now
uses new comunication protocol.
There are 2 options how to deal with this situation:
1) update current lvm code to support new libdevmapper-dm comunication
2) use old lvmtools and libdevmapper (ported by cl@) and update this
I thought that I will use monotone for this. I know how to work with
it and it works fine for me. But I can use cvs repo, too.
> 3. We need more file systems, and especially some more up to date
> ones. I am working behind the scenes to get physical block logging
> modifications to ffs. I have no idea if this will come off, it will
> depend on things outside my control. We need a back-up plan for this.
> ZFS can be done by refuse_lowlevel, which is a few days away from
> being committed. Other file systems have been made much easier by
> pooka's rump, but they still need to be worked on. We need support
> for checksummed metadata which doesn't compromise performance,
> distributed, clustered, journalled, and fast file systems which
> are not subject to a 2 TB limit. I know Greg has some ideas on
> this front, as have I.
> 4. Everything else I've missed.
> So lvm2 is a major priority, cleaning up the iSCSI stuff is next,
> and maybe new file systems come in between that.
> All feedback and progress gratefully received.
IMO wedges need much more testing, and we need documentation utilities
I have worked with ext3 support in my tree and it is pain, because
there is no documentation about how linux jbd works internally
therefore I think that we should try to port some really well
documented fs e.g. Mathew Dillon Hammerfs ?