Subject: Re: free space (was /dev) on tmpfs problem
To: YAMAMOTO Takashi <>
From: Daniel Carosone <>
List: tech-kern
Date: 11/14/2005 13:13:20
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 14, 2005 at 09:59:38AM +0900, YAMAMOTO Takashi wrote:
> > 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.

The -s parameter is useful to guard against malicious/greedy
applications, similar to process limits, and is useful for that.  I
don't think it's right that the admin needs to configure a limit to
guard tmpfs from other greedy parts of the kernel, especially dynamic
caches that are just making use of what would otherwise be slack.
This is mrg's point further up-thread, too.

I don't want a lower limit on tmpfs free space, I just want it to
correctly account for what it should offer as available.  What happens
when someone later tries to use that space is a different issue, for
the paging system to rebalance page usage types.  If tmpfs offers 0
free space because other types of memory have really used the space,
fine - but doing so for all file cache is silly.

Nor do I think that even if we have such a limit, they're the same
number.  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.  If we do have such a
reservation/minimum size, it should be a different number. Otherwise,
apart from more efficient storage, tmpfs is no better or more dynamic
than mfs in practice.


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.2 (NetBSD)