Messages in this thread | | | Date | Fri, 14 Jul 2000 15:22:29 +0200 (MET DST) | From | Bjorn Wesen <> | Subject | Re: Do ramdisk exec's map direct to buffer cache? |
| |
On Fri, 14 Jul 2000, Theodore Y. Ts'o wrote: > And the good thing is that we've already done that and it's already in 2.4 > :) It's JFFS, a completely log-structured system optimized for direct
> Very, very cool! I didn't know that. Sounds like very good stuff! > > So does it do compression as well? If not, please consider adding it, > as the iPAQ folks would love JFFS to pieces if it had that. >
It does not do compression yet although it would be simple to add it. Probably we'll add it in the 2.0 branch in parallel with the 2.4 version getting mature.
One thing that bugs me is that there seem to be a case of copy/paste in the kernel wrt compression code :) (there are more than one instance of inflate.c in the tree at least)
If we add it to JFFS there will at least be a deflate.c somewhere but the inflation can probably share code with cramfs which does the same thing as JFFS read-path will do in the compressed scenario.
> (They're very space limited on the amount of flash they have --- which > is not surprising if you're trying to run a complete Linux operating > system plus XFree86 on something that consumers can afford to buy.....)
Heh...
Couldn't they run cramfs for all the read-only stuff and just use the current JFFS for configuration/params ?
JFFS is not very optimal for thousands of files etc yet because it needs to keep the metadata in-core (there are no checkpoints in the log with node pointers) (like a permanent dentry cache)
-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/
| |