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