On Fri, 14 Jul 2000, Jim Gettys wrote:
> We suspect that a combination of cramfs and jffs will serve handhelds
> very well... I can say from first hand experience that compressed ramdisks
> and/or cramfs gets very old, very quickly: we really want a writable file
> system, with (read) compression.
Ok, that sounds like a useful embedded setup. Notice that when we've added
compression and made an improvement to the flash-sector allocator, you
could actually use JFFS only (with write-compression disabled) which would
provide the read-only files as pre-compressed (through the mkfs.jffs tool)
and stationary in their sectors, while handling the writable files into
the rest of the sectors. I guess enabling write-compression could be made
with a mount-flag.
(Right now the GC is a bit stupid and moves around nodes that don't really
change, so it's suboptimal to use it on a single partition with like 90%
read-only data..)
> A scheme Keith Packard proposed which would work very well for read only
> data is somewhat similar to cramfs: just compress on 4K boundaries
> and store an offset table, and mark the file as compressed when you are
> done; do the obvious uncompression on the marked files on read. My intuition
> is that this might be a performance win even on vanilla machines today.
The compression in JFFS will work similarly - nodes will be created with a
max-size limit (probably smaller using compression than without) and the
read_page routine will just uncompress the enclosing node(s) and give out
the data (in the special case of max-node-size == PAGE_SIZE it will be
especially simple of course (like in cramfs) and maybe that provides good
enough compression).
-Bjorn
-
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:20 EST