luks disk encryption benchmarks
Travis H.
travis+ml-cryptography at subspacefield.org
Tue Jun 5 20:00:51 EDT 2007
I just did some performance testing on a file server (debian 4.0) and
thought I'd share the figures, both raw and using the luks
cryptosystem described here:
http://luks.endorphin.org/about
Here's the specs:
AMD Athlon 64 x2 3600+ (1800MHz)
2GB 800MHz DDR2 ECC DRAM
Asus M2N32WS motherboard
3ware 9650SE SATA RAID controller (PCI Express) in PCI Express x16 slot
4 Seagate SATA-II 500GB 7200 RPM drives with NCQ in RAID 10 configuration
16kB stripe size
Debian 4.0 stable (etch)
# time dd if=/dev/zero of=/dev/sdb bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 23.0923 seconds, 45.4 MB/s
real 0m23.094s
user 0m0.000s
sys 0m4.508s
Now here demonstrates the luks cryptsetup overhead:
# time dd if=/dev/zero of=/dev/mapper/bulk bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 31.0872 seconds, 33.7 MB/s
real 0m31.089s
user 0m0.004s
sys 0m14.053s
So, with write-caching disabled, performance is fairly close.
Then I enabled write-caching and got this:
# time dd if=/dev/zero of=/dev/sdb bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 3.08291 seconds, 340 MB/s
real 0m3.126s
user 0m0.000s
sys 0m1.996s
That seems to reflect that it isn't really going to disk.
I'm surprised the controller has that much RAM on it,
really... so I ran this:
# time dd if=/dev/zero of=/dev/sdb bs=1024k count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 81.0223 seconds, 51.8 MB/s
real 1m21.024s
user 0m0.004s
sys 0m19.197s
Now here's the overhead with encryption:
# time dd if=/dev/zero of=/dev/mapper/bulk bs=1024k count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 151.202 seconds, 27.7 MB/s
real 2m31.227s
user 0m0.008s
sys 1m29.318s
Based on this, it looks like one of two things is happening:
Write cache is 2GB and encryption cancels it out
OR
Encryption reduces bandwidth by about a factor of 2 with write-caching enabled.
Now, for these filesystem tests I just used the default ext3... it does use
a journal, which will slow down writes, but this should give ballpark figures:
Here are the filesystem-level benchmarks without encryption (using LVM to make the filesystem 4G or so):
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
machine 4G 54305 96 84213 14 37749 8 52767 94 119217 13 436.6 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 5175 99 +++++ +++ +++++ +++ 5131 99 +++++ +++ 14419 99
machine,4G,54305,96,84213,14,37749,8,52767,94,119217,13,436.6,0,16,5175,99,+++++,+++,+++++,+++,5131,99,+++++,+++,14419,99
Here's the filesystem-level performance with encryption (again, with LVM on top of the encryption, file system 10G):
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
machine 4G 36692 98 79380 71 28544 6 50631 91 74157 9 464.5 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 5344 99 +++++ +++ +++++ +++ 5261 99 +++++ +++ 16060 99
machine,4G,36692,98,79380,71,28544,6,50631,91,74157,9,464.5,0,16,5344,99,+++++,+++,+++++,+++,5261,99,+++++,+++,16060,99
This presents a more interesting picture; it appears that for work on
actual files, the overhead is pretty modest... with all but
character-at-a-time input, it's not worth worrying about.
My hunch is that over NFS, even with gigabit ethernet, there will be no measurable
difference between encrypted and non-encrypted storage.
--
``To know love, be like the running brook, which though deaf,
sings its melody for others to hear.'' -- Master Po, "Kung Fu"
<URL:http://www.subspacefield.org/~travis/> -><-
For a good time on my UBE blacklist, email john at subspacefield.org.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20070605/6cbd7b93/attachment.pgp>
More information about the cryptography
mailing list