On 12 Jul 2000, Linus Torvalds wrote:
> The only problem with JFFS is that it doesn't do compression, so there's
> a lot to be said for using cramfs if you have space constraints (and in
> embedded devices, if you don't have space constraints you're doing
> something wrong ;). So mixture of ramfs, cramfs and JFFS can be a good
> thing.
Yeah.. we have compression in JFFS on our todo-list - the actual
compression/decompression is easy to add of course, but there is some
small trickery re. the GC (having to uncompress/compress blocks that need
to be split or merged).. and having to import Yet Another Compression
library into the kernel :)
Right now in our embedded products we actually have two flash partitions -
one containing read-only stuff (kernel + /) in romfs format, which is
inflated to DRAM at boot using the normal bootloader. The other is JFFS,
mounted to provide some R/W directories for configuration purposes. And a
ramdisk mounted on /tmp of course (we're still in the 2.0 dark age, hence
the stupidities :)
When we switch to 2.4 eventually, I'd expect the kernel image to still be
deflated to DRAM, but using JFFS for both the read-only and the R/W
partitions, with compressed nodes. And if that is not ready, cramfs for
the R/O stuff. ramfs for /tmp of course..
It should be mentioned of course that we designed JFFS for a 2.0 kernel,
and the current version in the 2.4.0 tree is mostly a port of that - there
are probably many things you would not want to do in the same way in 2.4,
for example the dentry cache trick used by cramfs is probably better than
JFFS caching the hierarchy itself. Will be fixed eventually..
Bjorn W (bjornw@axis.com)
-
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:15 EST