[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