Re: Announce loop-AES-v3.0b file/swap crypto package

[Fruhwirth Clemens <clemens@endorphin.org>]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

On Wed, 2005-01-19 at 12:03 -0500, Bill Davidsen wrote:
> On Tue, 18 Jan 2005, Dan Hollis wrote:
> 
> > On Tue, 18 Jan 2005, Venkat Manakkal wrote:
> > > As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
> > > system being changed in the past year, poor stability and machine lockups are
> > > what I have noticed, besides there is nothing like the readme here:
> > 
> > cryptoloop is also unusably slow, even on my x86_64 machines...
> 
> I'm obviously doing something wrong, I just copied about 40MB of old
> kernels (vmlinuz*) and some jpg files into a subdir on my cryptoloop
> filesystem, and I measured 4252.2375kB/s realtime and 18819.7879 kB/s CPU
> time. This doesn't seem unusably slow, even on my mighty P-II/350 and
> eight year old 4GB drives. The hdb is so old it has to run in pio mode, to
> give you an idea, and the original data was not in memory.

I've rewritten some CBC code to fit the facilities I introduce in my LRW
patch[1]. Here are the results for my P4@1.8GHZ:

loop-aes, CBC: ~30.5mb/s
dm-crypt, CBC prior to my rewrite: ~23mb/s
dm-crypt, CBC with my LRW patch: ~27mb/s
dm-crypt, LRW with my LRW patch: ~27mb/s (slightly faster than CBC)

As you can see my LRW patches (actually it's the generic scatterwalker
which is part of the LRW patch set) halves the gap to loop-aes. 

I'm sure dm-crypt is never going to achieve the speed of loop-aes.
That's just the price you pay, when you have to do things right and
clean, so they get merged into main. Kernel developers are choosey
customers, you know.

[1] http://clemens.endorphin.org/patches/lrw/

-- 
Fruhwirth Clemens <clemens@endorphin.org>  http://clemens.endorphin.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]