If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I've used encrypted home on Ubuntu since it became available. I have a Vertex2 SSD, but data transfers within home are limited to around 20 - 25 MB/sec, which maxes out one CPU core (Core2 Duo P8600). I don't so mind the slow speed so much as apps etc. still start lightning fast (only home is encrypted), but the fact that the CPU burns from simple copy operations is annoying, and it would be great if that work could be offloaded in my next machine.

Thanks for that info, I didn't notice 100% CPU usage during long operations. A bit strange it sucks so much power, but it seems we gotta live with it for now, waiting for more powerful CPUs to better utilize our super fast SSDs

Comment

My experience is that most semi-modern hardware handles disk encryption without much problem. Heck, I use dm-crypt/luks in Arch Linux on a Lenovo netbook with a 1.6GHz Atom CPU and a 250GB HD without any noticeable loss in performance.

Comment

My experience is that most semi-modern hardware handles disk encryption without much problem. Heck, I use dm-crypt/luks in Arch Linux on a Lenovo netbook with a 1.6GHz Atom CPU and a 250GB HD without any noticeable loss in performance.

Here's a simple test to time a 1 GB write, I would be interested to see your results. I'll post mine below. If you encrypt your whole root, maybe you can run the second test on your unencrypted /boot partition for testing purposes.

For me, the performance loss is noticeable by a factor of 10. And as I said, during the write to the encrypted space, one CPU core is constantly saturated, generating heat, causing fan noise, and increased power consumption. I think AES-NI would be very beneficial in my case, and probably even more so for reads than writes.

Comment

Damnit, I knew I would have to eat crow for that not so very carefully phrased statement :-)

I've run these dd's on both a 64-bit W500 Thinkpad laptop and the 32-bit Ideapad netbook, both running Arch Linux with dm-crypt/luks partitions on everything but /boot. I just did 250M though, because the /boot on the netbook is too small for a gig. /boot is ext3 and /home is ext4. This is what I get:

They are quite even over here but I am not sure about /dev/zero as a source. There is quite a bit of variation in these numbers if I repeat the tests. Does commit intervals for ext filesystems matter here btw?

I am not sure it matters much though. If I can take the liberty to rephrase my statement a little: without any noticeable loss in performance => without much noticeable loss in performance in day-to-day use. For instance, most long writes I do on the netbook consists of transferring movie files from my NAS to the disk and in such cases, the network is the limiting factor. I do not argue against having more of the crypto stuff in silicon, I just have not been hit by major performance regressions yet.

Moreover, it looks like your SSD is incredibly fast compared to my rotating disks. Perhaps the crypto overhead is low in my case compared to the I/O of my laptops...

Comment

Thanks for posting your speeds, some interesting stuff there. You're right, in your case 5 MB/s makes no practical difference in day to day use. Due to my high SSD speeds, it makes more of a difference for me.

What surprises me is that your 1.6 GHz Atom-based Ideapad is able to write to an encrypted partition at nearly 57 MB/sec when my Core2 Duo (2.4 GHz) can only write to an encrypted partition at 25 MB/sec (I've run the test a dozen times, it never gets over 26).

I'd be interested to find out why this may be. My first thought is that my encryption implementation is more CPU-intensive than yours. Ubuntu uses the AES cipher with a 16-byte key length (128 bit) for its home encryption from what I can tell from the mount command. What does mount tell you about your encrypted partition?

I also agree that dd is not the best approach to benchmarking this stuff but it's quick and dirty. Maybe I'll have a go with the phoronix test suite thing over the coming weekend...