ubsec(4) and geli(4) Benchmarks (WAS: Re: freebsd encrypted hard disk? (fwd))
All: Has anyone bench-marked the performance improvements associated with various ubsec models in conjunction with OpenSSL cryptodev acceleration of geli(4) in the kernel? I have a sneaking suspicion that I'm a pilgrim on unholy land here. I'm precluding hifn(4), padlock(4), and gblx(4), which are nice for offsetting low power CPUs on embedded platforms, from my question, and assuming that the only supported SSL accelerator that will actually 'compliment', as oppose to 'hinder' a multi-core Xeon system, when offloaded, is ubsec(4)? Thoughts? ~BAS -- Forwarded message -- Date: Thu, 15 Jan 2009 18:33:30 +0100 (CET) From: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl To: Roland Smith rsm...@xs4all.nl Cc: RW rwmailli...@googlemail.com, freebsd-questions@freebsd.org Subject: Re: freebsd encrypted hard disk? It turns out that on a multi-core machine a geli thread is started on each core for each disk (4 cores, two disks): and it is actually used when many transfers are done in parallel. my core2duo saturates (both cores 100% load) at about 100MB/s disk I/O ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd encrypted hard disk?
It turns out that on a multi-core machine a geli thread is started on each core for each disk (4 cores, two disks): and it is actually used when many transfers are done in parallel. my core2duo saturates (both cores 100% load) at about 100MB/s disk I/O ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd encrypted hard disk?
I read the encrypting disk partitions section of the Handbook. What is the preferred method nowdays, geli or gbde? Is there another method that would be better? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd encrypted hard disk?
Johann Hasselbach wrote: I read the encrypting disk partitions section of the Handbook. What is the preferred method nowdays, geli or gbde? Is there another method that would be better? I don't know what is best, but for quite some time I've used GELI to encrypt my entire hard disk, including the / partition. I then copy /boot to a USB thumb drive with the encryption key so I don't need any portion of the hard disk unencrypted. This setup also allows me to pull the USB key from the machine after it has been booted, taking the encryption key with me. I've never had a problem. pearl# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ar0.elia504M377M 87M81%/ devfs1.0K1.0K 0B 100%/dev /dev/ar0.elie 47G9.6G 34G22%/usr /dev/ar0.elif 47G7.2G 36G17%/var /dev/ar0.elig 47G 25G 19G57%/home Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd encrypted hard disk?
On Wed, Jan 14, 2009 at 12:23:09PM -0500, Johann Hasselbach wrote: I read the encrypting disk partitions section of the Handbook. What is the preferred method nowdays, geli or gbde? Geli seems to be the preferred method these days. It is also what I use to encrypt my /home. It works without problems for me. A geli-encrypted device gets the extension .eli. The boot scripts handle it automatically when they see an .eli device in /etc/fstab. Depending on how you configured it you might have to give the passphrase. You can even encrypt your root directory, but in that case I think you'll need an unencrypted partition for /boot. Is there another method that would be better? Depends on what you define as better. I don't think so. Geli is convenient and seems to work well. On modern machines the performance penalty is slight. It supports well-regarded encryption algorithms like AES and Blowfish. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpQoH9MuP8ed.pgp Description: PGP signature
Re: freebsd encrypted hard disk?
On Wed, 14 Jan 2009 12:23:09 -0500 Johann Hasselbach jhas...@gmail.com wrote: I read the encrypting disk partitions section of the Handbook. What is the preferred method nowdays, geli or gbde? Geli. Geli is more secure when used with real-world passphrases, supports hardware acceleration, and is faster, with or without out it. As I understand it, geli is also more reliable due to some operations being non-atomic in gdbe and atomic in geli. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd encrypted hard disk?
On Wed, 14 Jan 2009 18:59:54 +0100 Roland Smith rsm...@xs4all.nl wrote: Geli is convenient and seems to work well. On modern machines the performance penalty is slight. It supports well-regarded encryption algorithms like AES and Blowfish. It depends on what you mean by modern, and slight, on my single-core amd64 2.8G the performance penalty of geli is substantial. 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. I think most people find that filling a disk from /dev/random is slower than from /dev/null, or it at least has an impact on overall performance. And the /dev/random generator stage is AES encryption of a counter so the performance hit against /dev/null should be similar to writing to geli (and in my experience it is). And the faster your disks are, the more cpu speed you need to avoid cpu-limiting. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd encrypted hard disk?
On Wed, Jan 14, 2009 at 10:55:38PM +, RW wrote: On Wed, 14 Jan 2009 18:59:54 +0100 Roland Smith rsm...@xs4all.nl wrote: Geli is convenient and seems to work well. On modern machines the performance penalty is slight. It supports well-regarded encryption algorithms like AES and Blowfish. It depends on what you mean by modern, and slight, on my single-core amd64 2.8G the performance penalty of geli is substantial. True for a single-core machine. 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. Looking at the machines on sale at local computer stores only the absolute rock-bottom spec-ed machines are single core these days. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpiIy348Q02X.pgp Description: PGP signature
Re: freebsd encrypted hard disk?
On Thu, 15 Jan 2009 00:20:54 +0100 Roland Smith rsm...@xs4all.nl wrote: On Wed, Jan 14, 2009 at 10:55:38PM +, 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=1 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
