Subject: Re: Disk IO / UVM and Crypt FS..
To: Jorgen Lundman <firstname.lastname@example.org>
From: Jorgen Lundman <email@example.com>
Date: 05/09/2002 16:40:20
Thanks to Enami, Jaromir and Green for their help.
I've made the write operation allocate a new area, and crypt into it,
which appears to work and has improved write efficiency somewhat.
I did hit an issue with the crypto/blowfish area, the bf_cbc.c file,
which isn't really used, doesn't compile 'as is', that is fine, I've
modified it somewhat. The calling convention to bf_enc has changed too,
so I've modified it to follow suit.
That is, if anyone cares. :)
Blowfish-reference 1024bit key.
20971520 bytes transferred in 5 secs (4194304 bytes/sec)
Blowfish-i386 assembler 1024bit key.
20971520 bytes transferred in 2 secs (10485760 bytes/sec)
Jorgen Lundman wrote:
> enami tsugutomo wrote:
>>> Is there a solution for me? Would I have to produce a new "actual"
>>> buffer, which will be encrypted and put to disk and then dropped.
>> I guess so, since page cache may be shared among others. You need to
>> allocate new buffer, but you don't need to decrypt it.
> That does feel like the "proper way". Not too sure how to make a copy of
> the buffer, but that's good excertise. Would be tempting to only do it
> if I can detect a page is read-only, but I suppose it wouldn't be any
> more efficient not to copy, since I still would need to decrypt, and
> that generally is much heavier, computationally. (Ignoring the
> concurrancy issue as well!)
> Cheers for the insight,
Jorgen "Lord" Lundman <firstname.lastname@example.org>
Technology Manager, Unix Administrator
Phone: +44 (0)20-86591860 Mobile: +44 (0)79-58642918
"Rare is the person who can weigh the faults of others
without putting his thumb on the scales": Byron J. Langenfeld