Messages in this thread | | | Date | Thu, 13 Jul 2000 16:53:52 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Do ramdisk exec's map direct to buffer cache? |
| |
On Thu, 13 Jul 2000, Theodore Y. Ts'o wrote: > > 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.
Note that cramfs shares the compression algorithm side: everything is compressed as a 4kB block, because of the random-access issues. Going to bigger blocks is not _that_ much of a win, and gets painful on a small machine (and small machines is where this usually matters the most).
However, where cramfs shines is: _no_ fragmentation. Forget about block device issues, it does data on 4 byte boundaries. That, together with basically having very minimalistic meta-data (who needs meta-data anyway, when it's all read-only: _just_ enough to find stuff and no more) is the biggest win.
But you can't basically do these things if you want to be read-write. A truly log-based approach (ie not just meta-data journalling) might work out ok, actually, but most log-based stuff seem to want to have fairly large caches in order to work well. Which in embedded spaces isn't exactly a good idea.
Linus
- 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/
| |