Simple BDE disc encryption benchmark
Maxim Sobolev
sobomax at portaone.com
Mon Aug 9 02:42:11 PDT 2004
Daniel Eriksson wrote:
> Hi! I just ran a very simple benchmark on the GBDE disc encryption in
> CURRENT. The benchmark setup looked like this:
>
> * Slow machine (Celeron 366, 128MB mem)
> * 5-CURRENT from yesterday, running off of some old ATA disc
> * 2 x 9GB 10k rpm SCSI discs hooked up to an Adaptec 2940
>
> The benchmark was to copy the /usr directory (copied from the ATA disc,
> 1.7GB) or a directory containing big files (/bigfiles, 1.7GB in 16 files
> created by 'dd if=/dev/random ...') from scsi disc 1 to scsi disc 2. I ran
> each benchmark twice and took a simple average of the results.
>
> unencrypted to unencrypted:
> /usr : 697 real 10.6 user 235 sys (~50% idle)
> /bigfiles: 123 real 0.4 user 84 sys (~25% idle)
>
> unencrypted to encrypted:
> /usr : 1778 real 10.7 user 236 sys (~35% idle)
> /bigfiles: 379 real 0.4 user 82 sys (~10% idle)
>
> encrypted to encrypted:
> /usr : 1978 real 11.6 user 242 sys (~25% idle)
> /bigfiles: 615 real 0.4 user 80 sys (0% idle)
>
> The only time the CPU was completely busy was when copying /bigfiles from
> encrypted to encrypted.
>
> My question is: Why does the it take so much longer when encryption is
> involved even though 'top' seems to think there are CPU cycles left to burn?
The problem (well, not quite "the problem" since it is design decision)
is that GBDE tries to rearrange sectors in pseudo-random fashion to make
cryptoanalysis harder. Usually filesystem tries to place all sectors
that belong to the same file consequently, to avoid expensive disk
seeks. But on encrypted disk logically ajaced sectors are physically
spread, so that reading them introduces seek delays.
-Maxim
More information about the freebsd-current
mailing list