Date: Thu, 13 Jul 2000 14:39:38 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
A compressing JFFS sounds wonderful, although I suspect that even then it
might be useful to have a read-only side that compresses even better.
Compressed ext2 is horrible compression-wise. The metadata takes up
a large amount of space..
It's not the metadata that takes a lot of space, it's the fact that it's
using cluster cluster. That is, ext2compr takes a chunk of 8 1k blocks
(for example), compresses it down to 3100 bytes which takes 4 1k blocks
to store, and then stores it in 4 blocks, leaving a "hole" of 4 blocks.
Repeat for the next 8k chunk.
There are two major problems with this approach.
1) Every 8k (or whatever your compression cluster size is), you
end up resetting the compression algorithm. This makes for very lousy
compression ratios.
2) Because of the compression clusters, it means that you
suffer internal fragmentation and lose an average of 512 bytes (half the
1k block size) for every 8k of compressed data.
Why is it done this way? So that random-access reads (and especially
writes) work efficiently. If you are willing to live with two
constraints:
A) Files are written sequentially once, and ever written to
again. (appending is possible, but will be *slow*)
B) You have enough ram that you can afford to keep the entire
compressed file in memory at once --- or be willing to suffer nasty
performance penalties if you do random access seeks into the file.
It's possible to have much better compression ratios, since you don't
have to be the compression clusters game. However, many people would
find these constraints untenable, especially for a general purpose
filesystem. Life is full of tradeoffs.....
- Ted
-
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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:18 EST