First let me preface this by saying what the relevant system specs are: 3GHZ Athalon XP with 333FSB to .5GB RAM which should be the key players in encrytpion. There was no hardware encryption, but all relevant kernel stuff compiled in. The results were somewhat expected, that it took a little longer on average with the cpuProg times being hit the heaviest. But I was guessing on around a 5% to 10% increase, but for most filesystems I ended up with less than a 1% increase. Also looking in detail at the output, Reiser still had the same bizarre jumping behavior that kept it's averages somewhat low but was unreliable in general. Below are some charts(No I can't use GNUplot!) that measure the difference between averages with and without encryption on various filesystems with some different AES types for the total times as well as the average times between all types of tests for each fs. Click for a larger version:
As always JFS and XFS are the clear winners, with XFS slightly better in all the tests. And in conclusion I think I will be using XFS since it seems to be the fastest, is consistent, and has a bit more support(Official for BSD IIRC) than JFS. Also encrytpion is suprisingly quick even with all out 256 bit AES the increase is less than a percent(Except for Reiser). Also after several runs I could never see a big difference with or without SHA256 hashing and sector salt, so no reason to not use it. Personally I think I will use 128 bit AES with salt and SHA256 hash with XFS on everything and see how it goes.
Everything was done using dm-crypt(Which is a loopback encryption scheme) without LUKS. The script used cyptsetup commands such as:
..echo pass | cryptsetup -c aes-cbc-essiv :sha256 --key-size 128 /dev/hdc5 mountPoint
to appropriately set up the mappings.
A general quick rant...WTF is wrong with reiser? It does seem to do much worse with encryption than the others, and it is always WAY varied, it's almost impossible to guess how long disk IO will take with it. It would be mind boggling to use in real life, it would seem too quick and you'd worry if it really got copied or take too long and you'd worry it froze. Heuristically determined IO is a cool idea, but seems half retarded if anyone ever used it in a production server since you can make no gaurantees! For me I'm staying the hell away with anything labeled Reiser for quite a while. Other benchmark things I've read talk about how after multiple trials Reiser4 is slow on average too(Some rate it worse than normal Reiser), so I don't feel the need to dick with it . Reiser should be ashamed of itself for completely being schooled by FAT..maybe if I close my eyes it will just go away.
0 comments:
Post a Comment