> > > So there are two problems:
> > >  1. tmpfs is not reporting free space sanely for df
> > >  2. tmpfs is apparently not allowing itself to compete with file cache
> > >     for free-memory resources.
> > 
> > yes, and my suggestted patch (mandate -s) solves both of them.
> 
> Earlier up thread, you said you don't consider teaching tmpfs about vm
> details desirable.  Fair enough. I guess we differ on what we think is
> desirable, and you're talking about implementation while I'm talking
> about behaviour.  I don't think your patch brings desirable behaviour.

yes, my desire is different from yours.
i understand your desire, but i dislike it.

> Put another way: with your version of -s, do we have to teach
> the vm system not to steal pages the admin has 'promised' to tmpfs
> with -s?  Otherwise, when the machine fills with process anons, tmpfs
> will report free space it can't use.

in that case, it can wait for memory ~forever.
i don't see it as a serious problem because it just mean
what admin specified was unreasonable.

alternatively, it can return ENOSPC.  in this case,
df won't show what you want.

in either way, i don't see any problem.  as tmpfs is not
a normal filesystem, what df show might not be the same as
what you expected for normal filesystems.  so what?
it merely means that you need to change your mind.

> Otherwise,
> apart from more efficient storage, tmpfs is no better or more dynamic
> than mfs in practice.

mfs is not so bad, IMO. :-)

to me, "dynamic" sounds uncontrollable here.

YAMAMOTO Takashi