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

On (29/03/2012 21:49), O. Hartmann wrote:
> Am 03/29/12 18:14, schrieb David Wolfskill:
> > On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote:
> >> I was wondering if there are some objections using TMPFS for /tmp and
> >> /var/run.
> >> ...
> >> My question is whether there are objections using TMPFS for bot /tmp/
> >> and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64?
> >> ....
> > 
> > I have no experience using tmpfs for /var/run, but I have been using it
> > for /tmp for some time (mostly in i386, though).
> > 
> > While I use it quite successfully on machines with a small number of
> > folks actively busy -- e.g., my desktop; my laptop; my home machines), I
> > encountered some issues when I tried to do so on machines that were
> > intended for significantly "heavier" use.  Specifically:
> > 
> > * Compared to an md-resident /tmp, a tmpfs-resident /tmp has much less
> >   flexibility for specifying the size.  Per mdconfig(8), the former
> >   uses:
> > 
> >      -s size
> >              Size of the memory disk.  Size is the number of 512 byte sectors
> >              unless suffixed with a b, k, m, g, or t which denotes byte, kilo-
> >              byte, megabyte, gigabyte and terabyte respectively. Options -a
> >              and -t swap are implied if not specified.
> > 
> >   while the latter uses:
> > 
> >      size    Specifies the total file system size in bytes.  If zero (the
> >              default) or a value larger than SIZE_MAX - PAGE_SIZE is given,
> >              the available amount of memory (including main memory and swap
> >              space) will be used.
> > 
> >   In this configuration, I would have preferred to have specified
> >   about 10GB for /tmp.  I wouldn't mind if it spilled to swap space,
> >   but I certaianly didn't want it using 10GB of RAM -- especially since
> >   the machines only had 6GB RAM.
> > 
> >   Nor did I especially want *all* of the swap space used for /tmp.  I
> >   would have allocated (say) 20GB for swap.  I wouldn't mind if half of
> >   that were used for /tmp -- but a reason I allocate so much swap is
> >   that I've seen what happens when a machine runs out of swap, and it
> >   wasn't pretty.
> > 
> > 
> >   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.

> > 
> > * 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.

> > So I continue to use tmpfs for /tmp for machines with fewer folks
> > logging in, but I'm a bit less enthusiastic about its use unless the
> > workload and other requirements are fairly carefully considered
> > beforehand.
> > 
> > Peace,
> > david
> 
> 
> 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

Thanks,
Gleb.

> 
> On the other hand - my view of those things is really naiv. I think
> having tmpfs isn't even a benefit in terms of security, it should also
> offer a speedy access to files kept in memory, doesn't it?
> 
> Linux is using TMPFS filesystems a lot for these purposes. How do they
> overcome restrictions of the size or not flloding RAM and/or swap?
> 
> Regards,
> Oliver
>