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

Re: Re: dm-crypt/LUKS performance



> Which Debian release? Kernel? Motherboard make/ model? CPU model? RAM module(s)
> make/ model? SSD exact model? Defaults? Customizations?
My initial post was indeed a little light on details, so here's more info: I'm dealing with a pristine installation of Wheezy. It is running on a Supermicro A1SAi-2750F with 16GB of Kingston SODIMM RAM and a Intel c2750 Avoton octo-core. The drive I was referring to in my tests is a Samsung 840 PRO with 128 GB.
There's no load on the system what-so-ever other than the tests I'm running.

I measured read/write speeds by a) writing/reading directly to/from the partition, b) cyrptsetup luksFormat + cryptsetup luksOpen and then writing to the corresponging /dev/mapper/<name> device. No LVM or other indirections involved as someone else suggested might have been the case.

> That SSD appears to have hardware encryption.  So, why dm-crypt?
Basically, what someone else already said - "hardware encryption" on SSDs is not really useful or trustworthy.

> I assume those are non-default option values. Predicting and measuring how each of those are 
> affected by AES-NI would be a non-trivial task. You might want to try some benchmarks using the 
> defaults first, and then go from there.
I've tried a few options, mostly different key sizes, with similarly bad performance penalties.

> Did you do a secure erase on the SSD prior to the write tests? SSD's can write to fresh blocks faster 
> than they can reclaim old blocks, erase them, and then write.
I didn't erase/trim anything from the drive. However, it is a brand new drive that hasn't had more than a few GB written to it in its lifetime, so I wouldn't think this is an issue. Also, I'd expect degrading SSD performance to affect both encrypted and non-encrypted writes (and it really shouldn't affect any of the reads).

> Your first write test is 256 MB, but all the other tests are 512 MB. Why the unequal size?
As you point out, my tests were certainly not very systematic or scientific and might even be completely non-representative of any real-world workload. If I have the time, I will grab another spare drive, and run some more thorough tests. As crude as my tests were, though, I'm still baffled by the results. 

Thanks,
- Dave.

Reply to: