-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I don't think that hdparm is a good way to test the performance of a LUKS partition, as - I think - hdparm only tests the reed speed of a device, not of a partition. I.e. If you test a drive with it, I think it reads raw data without decrypting it. To test the decryption speed you could use a timed copy of a file to /dev/null: # time cp sourcefile /dev/null should give you the overall net performance. Comparing a sourcefile on an unencrypted with an encrypted partition should give you an idea how LUKS slows your system down. To give you a comparison, here are my performance data: Any comments on improving the test methodology are welcome! I have a Pentium 3 800 MHz CPU, 640MB of RAM. I use a RAID 5 setup of 4 80GB Seagate Barracuda 4 disks to build a partition which is LUKS encrypted and a 20GB Seagate Barracuda 4 disk as a system disk, not LUKS encrypted, with encrypted swap. I operate 2 of my RAID disks + the system disk from the on-board controllers and the other 2 from a promise PCI IDE controller with 2 channels. The 4 80GB disks are RAID-5-ed to /dev/md2 and on this partition I cerated a LUKS volume /dev/mapper/luks1 I did a series of tests to evaluate the performance: 1: I tested the performance of the disks with hdparm: Typically, each one of my Seagate drives gives a read performance of 20MB (on board controller) to 40MB (PCI controller) # sudo hdparm -t /dev/hd[a-x] /dev/hda Timing buffered disk reads: 62 MB in 3.09 seconds = 20.04 MB/sec /dev/hde: (Controller prim master) Timing buffered disk reads: 122 MB in 3.05 seconds = 40.01 MB/sec Also, I tested it by reading 500MB of raw data from the disks: # sudo dd if=/dev/hd[a-x] of=/dev/null bs=5000000000 count=1 It gives the same 20-40 MB/sec 2: I tested the performance of the RAID 5 system UNENCRYPTED by reading from /dev/md2: # sudo dd if=/dev/md2 of=/dev/null bs=500000000 count=1 500000000 bytes (500 MB) copied, 12.5872 seconds, 39.7 MB/s So, I can read at 40MB/s from the RAID 5 array, system, which is good. 3: I tested the influence of encrypting with LUKS: this time the input file is the luks partition /dev/mapper/luks1 # sudo dd if=/dev/mapper/luks1 of=/dev/null bs=500000000 count=1 500000000 bytes (500 MB) copied, 38.7348 seconds, 12.9 MB/s So, performance is down to 13MB/sec by encryption. 4: to verify this, I copied actual files from the LUKS volume to Nirvana: # time cp "some 700MB file from the luks partition" /dev/null 730322944 bytes, 56.435 = 12.34 MB/sec So, the results of dd and cp agree well. 5: my linux box servs as a NAS, so I also copied the same file to one of my client computers running also linux over a 100MB LAN: # time cp "some 700MB file on the LUKS NAS" /dev/null 730322944 bytes, 83.73 sec = 8.3 MB/sec What can be expected from an 100MBit Ethernet connection, taking protocol overhead into account. Conclusions: My 800MHz CPU is fine for RAID-5 XOR calculations. The LUKS encryption slows it down considerably, from 40 to 13 MB/s It still suffices to saturate the ethernet bandwidth. To do better, 1st gigabit ethernet and 2nd a faster CPU would be needed. If I haven't misunderstood something fundamental completely, my tests could help you benchmark your system. Greetinx, Wolfgang Tomasz Chmielewski wrote: > I just set up an encrypted LUKS device using the information on > http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDeviceUsingLUKS > > There was a suggestion there, which prompted me to check the performance: > > If you wish, use /sbin/hdparm to benchmark. However my benchmarks on > an AMD Athlon 3200 indicate no great difference between an encrypted > and a normal unencrypted partition. > > > First, I set read-ahead to the same value on both devices (original LVM > device, and the crypted one): > > # blockdev --setra 16384 /dev/mapper/crypttest > # blockdev --setra 16384 /dev/mapper/san1-test > > > Next, hdparm test: > > # hdparm -t mapper/crypttest mapper/san1-test > > mapper/crypttest: > Timing buffered disk reads: 116 MB in 3.01 seconds = 38.54 MB/sec > HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate > ioctl for device > > /dev/san1/file1-swap: > Timing buffered disk reads: 304 MB in 3.12 seconds = 97.46 MB/sec > HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate > ioctl for device > > > So, this quick test suggests that with a crypted device, I get about 40% > performance of the original LVM volume? > > > My setup is hardware RAID-10, and a dual core 3 GHz Xeon. > > Is it normal? I would say yes, as both cores use 100% CPU when I do > intensive reads from an encrypted volume. > However, this seems to contradict with "However my benchmarks on an AMD > Athlon 3200 indicate no great difference between an encrypted and a > normal unencrypted partition". > > > I used aes-cbc-essiv:sha256 cipher. > > Perhaps, I should use something lighter? > > > - -- Poets say science takes away from the beauty of the stars - mere globs of gas atoms. Nothing is 'mere'. I too can see the stars on a desert night, and feel them. But do I see less or more? Richard P. Feynman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3r7uR6b2EdogPFsRApx2AJ9P6GYAeNrQ8y1DBfpzasB9AO61pgCeLtQi kITo6wDBPkuj6Js5DCQbIjU= =z9Ju -----END PGP SIGNATURE----- --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
