Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] dm-crypt overhead (was Re: TrueCrypt with SSD)



On Mon, Aug 29, 2011 at 11:59:45PM -0400, Edward Ned Harvey wrote:
> > From: Derek Atkins [mailto:warlord at MIT.EDU]
> > 
> > This is a spinning disk, not SSD, but as you say it should be able to
> > sustain 1Gb/s.  It's not.  I'm only getting 400Mb/s to the disk through
> > dm-crypt.  
> 
> Well, I only made a generalization.  ;-)  What does your drive mfgr publish
> for specs on that drive?   Nevermind.  Try this...
> 
> Use dd to read from /dev/sda (or whatever) dump to /dev/null.  This will
> prove the sequential hardware read speed of the disk without encryption.
> 
> Then create a large file (repeat the above dd command, but read from
> /dev/zero and write to a file.)  If you feel like it, reboot just to ensure
> nothing is cached or buffered.  Read the file.  Now the only thing you've
> done is add filesystem overhead and encryption overhead.
> 
> That should be a pretty good test, to see if encryption is really the
> bottleneck for you...  At least for reading.  But as you said, without any
> free space on the drive, it's hard to test writing without encryption.

For disk benchmarks, try these:

Tests reading from buffer cache and from disk, respectively.  You can
run this on the underlying device and the dm-crypt device and on any
other intermediate layers (e.g. mdraid, LVM) to guage the performance
differences between each layer, e.g.:

hdparm -T -t /dev/sda1
hdparm -T -t /dev/md0
hdparm -T -t /dev/mapper/foo
hdparm -T -t /dev/mapper/luks-foo

Performs various read/write benchmarks against the filesystem.  This
will create a large file in the current directory and perform
read/write benchmarks.  It will also create a directory full of files
for create/read/delete benchmarks:

bonnie++ 



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org