Re: dm-crypt using kthread

[Grzegorz Kulewski <kangur@polcom.net>]

On Sun, 15 Feb 2004, Jeff Garzik wrote:

> Grzegorz Kulewski wrote:
> > Could somebody write dm-compress (compressing not encrypting)? Is it 
> > technically possible (can device mapper handle different data size at 
> > input, differet at output)? (I think there is compressing loop patch.)
> > Could dm first compress data (even with weak algorithm), then encrypt, to 
> > make statistical analysis harder?
> 
> 
> It's certainly possible, but you have to consider that data transfer 
> almost always should be considered in page-sized chunks.  For compress 
> that would imply you would need to allocate/free blocks and similar 
> duties that a filesystem must perform, simply because you do not have 
> one-to-one correspondence with blocks being passed to you.
> 
> You also have to consider that the kernel may request one or more pages 
> that are in the middle of a compressed run of pages.  For example, 
> consider an algorithm that compresses 16 pages into a run of 4 pages. 
> Later on, when the kernel requests (uncompressed) page 9, you likely 
> need to read all 4 pages, and allocate 16 more pages for decompression. 
>   So, reading 1 upper layer page required dm-compress tying up 20 pages.
> 

Yes, I understand that (at least I think so...). But Knopix (and probably 
other distros) use 2.4 with compressing loop patch, and I think somebody 
at Gentoo is trying to port that patch to 2.6 for Gentoo's LiveCD... So it 
was done somehow... (I do not know how, however.)


Grzegorz Kulewski