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)


Lund



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,
> 
> Lundy
> 
> 


-- 
Jorgen "Lord" Lundman <lundman@lundman.net>
Technology Manager, Unix Administrator
Phone: +44 (0)20-86591860  Mobile: +44 (0)79-58642918
Pager: 07958642918@one2one.net
"Rare is the person who can weigh the faults of others
  without putting his thumb on the scales": Byron J. Langenfeld