lkml.org 
[lkml]   [2000]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.095 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site