I got myself a new toy - The Intel SSD 600p 1TB M.2 NVMe disk. Before I bought it, I tried to figure out how big the performance penalty for using full disk encryption would approximately be. But I wasn't able to find much on this topic. Now that I set it up, I want to share some benchmarks of how an encrypted LUKS+Ext4 partition performs in comparison to just using Ext4.
All benchmark runs were made with GNOME Disks on a Lenovo Thinkpad T460s with a Core i5-6200U
CPU running Ubuntu 16.10 Yakkety Yak (Kernel 4.8.0-37-generic x86_64) and KDE. The
encrypted partition was set up via GNOME Disks.
LUKS+Ext4
|
1 MiB Block Size |
|
10 MiB Block Size |
|
100 MiB Block Size |
|
1000 MiB Block Size |
The 1000 MiB block size attempts were inconsistent. After a minute of waiting before doing another run, I got the above result. Many look like the two runs below. It is either a temperature or caching effect I guess.
|
1000 MiB #2 |
|
1000 MiB #3 |
Ext4 Only
|
1 MiB Block Size |
|
10 MiB Block Size |
|
100 MiB Block Size |
|
1000 MiB Block Size |
Evaluation
- Just reading/writing data at 1.8/0.6 GB per second takes CPU time, regardless of whether encryption is enabled or not
- LUKS+Ext4 incurs signifcant extra CPU work over just using Ext4. Notice that the CPU uses all four threads for the encrypted partition, but just one or two threads for the unencrypted one.
- Access time according to GNOME disks is similar. The difference is less than a factor of 2 in all cases.
- 1 MiB Block Size: Encryption incurs a bandwidth penalty of factor 2 to 4.
- 10 MiB: There is a read slow down factor of 2 with encryption. Writing is not much slower.
- 100 MiB: The encrypted drive alternates between 1.7 GB/s and 1.0 GB/s read speed for some reason. Writing looks OK.
- 1000 MiB: You get almost full speed.
No comments:
Post a Comment