Messages in this thread |  | | | Date | Sun, 15 Feb 2004 23:05:02 -0500 | | From | Jeff Garzik <> | | Subject | Re: dm-crypt using kthread |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |