Re: dm-crypt using kthread

[Jeff Garzik]

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.

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/