Re: Using TMPFS for /tmp and /var/run?

From: David Wolfskill <david_at_catwhisker.org>
Date: Mon, 2 Apr 2012 03:59:33 -0700
On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote:
> ...
> > >   In any case, effective maximum usable size for tmpfs involves SIZE_MAX
> > >   (~4G) & PAGE_SIZE (4K, in my case).
> 
> size_t is 64-bit on 64-bit archs.

OK.  Still, the requirement that the "size" specification be in "bytes"
is awkward (in my experience) -- and I was using i386.

> > > * Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC
> > >   whenever I tried to allocate anything on it -- until I dropped the
> > >   size specification to <2G (2**32).  Well, 2GB for /tmp just wasn't at
> > >   all likely to be useful for my purposes in this case.
> 
> Are you using ZFS alongside tmpfs? It should be fixed in 9-STABLE.

I have not tried ZFS yet.  I don't expect to do so unless I switch to
amd64.

> ...
> > It seems there is only one switch which determines the size of the tmpfs
> > in question (size) and there is no convenient way to say what amount of
> > RAM is being used before using the swap space. I'd like to have at least
> > a knob determining the limit of RAM being used.
> 
> There is no way to force tmpfs to use given amount of RAM only. It's VM
> subsystem that decides what pages to swap. Although some tweaking for VM
> to prefer swapping tmpfs pages prior to process pages would be nice.
> 
> You could try the patch attached. It adds support for size option suffixes
> (like 1g) and introduces swap limit (part of the older patch, not sure
> if it's any use).
> 
> Patch is against 10-CURRENT.
> Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d
> ...

I'll plan to try this on a currrently-underutilized slice on my laptop,
then -- thanks! :-)

Peace,
david
-- 
David H. Wolfskill				david_at_catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Received on Mon Apr 02 2012 - 08:59:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC