Subject: re: free space (was /dev) on tmpfs problem
To: None <mrg@eterna.com.au>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 11/15/2005 12:56:56
>    > (linux tmpfs also uses virtually no extra ram due to using
>    > other kernel cache objects (ie, vnode/inode/directory) rather
>    > than keeping track of them with private structure.  i wonder
>    > if those ideas could be adapted for our tmpfs?)
>    
>    i guess it just means linux have to use extra ram for
>    mandated namecache (dcache) otherwise.
> 
> 
> do we currently duplicate his data?  it seems no matter where
> it goes, not duplicating data should save memory as well as
> potentially avoid stale-data use (though this really would
> indicate a bug somewhere i think?)

i don't understand what you mean.
what's "his data"?  how you can see stale-data?
do you undestand how our and their tmpfs is implemented?

i'd rather want to see tmpfs implementation which can page-out any data,
including directories and inodes.
so i'm against coalescing in-core objects.

YAMAMOTO Takashi