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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:18 EST