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