lkml.org 
[lkml]   [2000]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Do ramdisk exec's map direct to buffer cache?
Date
In article <2947.963395714@cygnus.co.uk>,
David Woodhouse <dwmw2@infradead.org> wrote:
>
>My current inclination is to make CONFIG_BLK_DEV a config option, turn it
>off to save space, and use JFFS directly on flash chips, with ramfs for /tmp
>and possibly also /var
>
>I'm fairly sure that ramfs does share pages as you'd hope it does.

ramfs does indeed share pages, and does more than that: it shares the
directory structure with the directory cache directly, so there is not
any wasted memory even in meta-data. That was one of the design goals
(along with extreme simplicity - it's the smallest and fastest
filesystem around).

That said, ramfs isn't perfect. It's not a "tmpfs" in that it cannot
page anything out to disk (a non-issue in embedded devices, but it would
make ramfs more useful in general use), and it's new code that isn't
used by all that many people - so it could have (and has had) problems.
As 99% of the functionality of ramfs is actually just using VFS code
directly the basics of ramfs are very solid, but the devil is in the
details..

If you want to pre-populate ramfs (the way initrd does the old-style
ramdisk), I would suggest using a compressed tar-file approach. In the
long run I definitely want to get rid of the old-style ramdisk, as it
has some serious problems both from a design standpoint and from a
maintenance angle (the mm games it plays are much worse than the simple
page-pinning stuff that ramfs can do - ramfs plays at a much higher
level and has access to better abstractions through that).

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.

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/

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