freebsd encrypted hard disk?

[RW]

On Thu, 15 Jan 2009 00:20:54 +0100
Roland Smith <rsmith at xs4all.nl> wrote:

> On Wed, Jan 14, 2009 at 10:55:38PM +0000, RW wrote:

> > Not just in reduced transfer rates, but also in terms of CPU cycles
> > used - a sustained geli to geli file copy makes things really slow
> > for me.
> 
> That's probably because two geli kernel threads are competing for time
> on a single core. I've had problems with that as well (geli-encrypted
> USB drive stalling).
> 
> Since I've switched to a multi-core machine (where the number of cores
> should be at least equal to the number of geli-encrypted devices), CPU
> load for gele has dropped to barely noticable.
> 

I find that puzzling; have you measured that on sustained geli to
geli transfers (with GB size files).

The reason I'm a bit sceptical is that dd'ing /dev/random to /dev/null
runs at about 20MBytes/s on my single core (verses 700MBytes/s
for /dev/zero). File copies into geli run at about 15Mbytes/s, openssl
enc -aes-256-cbs runs at about the same ballpark figure. Even if I had
multi-cores I would still be cpu-limited to 20MB/s, and that would fully
occupy two cores on geli to geli transfers. Your cores are probably
faster, but I'd expect a factor of two or so would be swallowed-up by
faster transfers. I don't see how cpu usage would be negligible unless
your individual cores are an order of magnitude faster than that.

Just out of curiosity what rate do you get on  
dd if=/dev/random of=/dev/null bs=64k count=10000

> Looking at the machines on sale at local computer stores only the
> absolute rock-bottom spec-ed machines are single core these days.

My guess is that you really need quad cores for best performance, so
you avoid having all cores in geli.