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 biased. Aggelos
