Subject: re: free space (was /dev) on tmpfs problem
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
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.