Date: Mon, 09 Aug 2004 12:42:03 +0300 From: Maxim Sobolev <sobomax@portaone.com> To: Daniel Eriksson <daniel_k_eriksson@telia.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Simple BDE disc encryption benchmark Message-ID: <411746EB.5030006@portaone.com> In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAApKSdNgL8EkaHhtB/cG3DrwEAAAAA@telia.com> References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAApKSdNgL8EkaHhtB/cG3DrwEAAAAA@telia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?411746EB.5030006>