Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: 2.4 Features | Date | Wed, 9 Feb 2000 20:42:54 +0100 (MET) |
| |
"A month of sundays ago Alexander Viro wrote:" > > problem with the pagecache and e2compr anyway? Thinking about the > > implications of an indirection layer, I don't see any. E2compr doesn't > > use more than a real physical page of memory at a time? > > Yes, it does. And that's where the pain comes. File is divided into groups > of pages and every group is compressed separately. Unfortunately, you
Surely this is compression algorithm dependent! AFAIR all the compression algorithms avaiolable in e2compr are block compression algorithms. Plenty of them can be blocked 4K at a time. If I remember even more correctly, that is one of the default choices (and if I remember even more and more correctly, I usually change it to 32K to get better ratios, since gzip is fast on decompress, and my cpu is faster on compress than the disk is on write).
If the above is right, then all one has to do for the moment is disable e2compr compression blocks of more than PAGESIZE.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |