Re: iSCSI, lvm, storage and the future

[Adam Hamsik <haaaad%gmail.com@localhost>]

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
> projects.
>
> 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  
> roadmap
> for NetBSD, and put that up on the website.
>
> This won't have dates beside it, for obvious reasons, but I expect  
> we'll
> start looking at branching 5.0 sometime in February/March, and so  
> having
> as many components of the storage side of NetBSD in place by then  
> would
> 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  
> removal
> 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  
> know,
> 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  
protocol.
2) use old lvmtools and libdevmapper (ported by cl@) and update this  
later.

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

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 ?


Regards

Adam.