[NCLUG] Encrypted Filesystems?

Bob Proulx bob at proulx.com
Sun Apr 15 18:33:24 MDT 2007


> You can't get something for nothing.

Wanting to characterize the performance penalty I installed three
different configurations on the same laptop and benchmarked using
bonnie++.  The laptop is an IBM Thinkpad T42 Pentium M 735 1.7GHz with
a 5400rpm 80G disk.  I clamped the ram to 512M for this test so that
file sizes bonnie needed to avoid the buffer cache would not be too
large and would not take too long.  I installed Debian Etch for this
test.

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
none             1G 20813  62 21960   7  8210   2 17339  46 18144   2 126.0   0
aes128           1G 19247  56 22154   9  9358   2 18675  49 22030   2 135.2   0
aes256           1G 17252  50 27740  14 12110   2 14528  39 28246   3 141.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
none             16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
aes128           16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
aes256           16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

In the first case no encryption was used.  I did use lvm because I
used lvm for the encrypted cases and this way all three went through
the lvm layer.  An lvm volume was created with a 4G logical volume for
swap and another logical volume rest for the root filesystem.

The second case used AES with 128 bit encryption with dm-crypt.  Then
an lvm volume was created using the encrypted partition with a 4G
logical volume for swap and the rest for the root filesystem.

The third case used AES 256 bit encryption but was otherwise identical
to the second case.  I expected this to be the slowest case since it
had the strongest encryption.  Counter to what I expected it was
faster in some cases.

All three installations were as similar as I could make them.  All
used ext3 filesystems.  All had the identical base Debian Etch system
installation fresh and then install bonnie++ and then run the test.
All three used mem=512M to avoid bonnie running for hours.

If I had thought about it ahead of time I would have increased the
number of files so that the file create portion of the benchmark would
have had some useful data.  But I didn't and so this is the data that
I have in my hand.

Some of the data would appear to be backward to what I would have
expected.  I can imagine that sometimes the overhead is actually low
and so normal system variations occurred.  In other cases I think the
algorithm is optimized for particular bit sizes and suffers when not
at the optimized size.  But for some of the data I can't explain it.
It seems too wacky.  I think the filesystem buffer cache also really
covers up most of the performance penalty and confounds the data.

Comments?

I am inclined to say that going for AES 256 bits through dm-crypt and
encrypting the entire filesystem is perfectly reasonable for a
moderatly powered laptop and that for the most part it is not
noticeable to the user.

Bob



More information about the NCLUG mailing list