DragonFly BSD
DragonFly kernel List (threaded) for 2010-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Google Summer of Code idea

From: Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>
Date: Wed, 31 Mar 2010 17:03:25 +0300

Chris Turner wrote:
> Aggelos Economopoulos wrote:
>> Dare I point at the device mapper GSoC project which includes
>> implementing the crypt target? I think that's generic enough (;P) and
>> would also get us mature volume management for free.
> right right..
> devils advocate: with hammer PFS (and perhaps quotas) -
> do we even *need* volume managment?

No, we can just duplicate a shitload of work inside hammer. And then
reinvent another wheel adding crypto support for vn(4). With the magic
devfs interface, sure. Although stacking encryption on top of raid or
vice versa is going to make the interface look a bit less sexy and you
need to provide a userspace tool to do the ioctls anyway. Throw in a few
more wheels for features like multipath or delay (you can stick all
those in raidctl I suppose, not sure what kernel implementation you'd
want to use). Now all you need is to find the people who are going to
implement and maintain the whole thing.

Just playing the daemon's advocate here :)

> my 'fantasy' io framework:
> - openbsd softraid / raidctl
> - hammer + pfs quotas

Yah, well, it could be made to work. But I see some problems with that
approach as you might guess from the above :) I'm all for pooling our
developer resources with other BSDs (i.e. not just copying their code,
but helping with development in the directions we care about) and my
impression is NetBSD's dm port is more suited for us ATM.

But hey, I got my fileserver off OpenBSD because I wanted real volume
management and that wasn't even on the roadmap, so I admit I could be


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]