tmpfs is zero bytes (no free space), maybe a zfs bug?

[Ivan Voras]

On 7 February 2011 14:37, Gleb Kurtsou <gleb.kurtsou at gmail.com> wrote:

> It's up to user to mount tmpfs filesystems of reasonable size to prevent
> resource exhaustion. Anyway, enormously large tmpfs killing all your
> process is not the way to go.

Of course not, but as I see it (from admin perspective), tmpfs should
behave as close to regular processes in consuming memory as possible
(where possible; obviously it cannot be subject to the OOM killer :)
).

The problem described in this thread is that there is enough memory in
various lists and tmpfs still reports "0 bytes free". See my message:
the machine had more than 8 GB of "free" memory (reported by "top")
and still "0 bytes free" in tmpfs - and that's not counting inactive
and other forms of used memory which could be freed or swapped out
(and also not counting swap).

By "as close to regular processes in consuming memory" I mean that I
would expect tmpfs to allocate from the same total pool of memory as
processes and be subject to the same mechanisms of VM, including swap.
If that is not possible, I would (again, as an admin) like to extend
the tmpfs(5) man page and other documentation with information about
what types of memory will and will not count towards available to
tmpfs.

> Unless there are objections, I'm planning to do the following:
>
> 1. By default set tmpfs size to max(all swap/2, all memory/2) and print
> warning that filesystem size should be specified manually.
> Max(swap/2,mem/2) is used as a band-aid for the case when no swap is setup.

You mean as a reservation, maximum limit or something else? If a tmpfs
with "size" of e.g. 16 GB is configured, will the memory be
preallocated? wired?

I don't think there should be default hard size limits to tmpfs - it
should be able to hold sudden bursts of large temp files (using swap
if needed), but that could be achieved by configuring a tmpfs whose
size is RAM+swap if the memory is not preallocated so not a big
problem.

> 3. Remove "live" filesystem size checks, i.e. do not depend on
> free/inact memory.

I'm for it, if it's possible in the light of #1

> 2. Add support for resizing tmpfs on the fly:
>        mount -u -o size=<newsize> /tmpfs

ditto.

> Reserving swap for tmpfs might not be what user expects: generally I use
> tmpfs for work dir for building ports, it's unused most of the time.

It looks like we think the opposite of it :) I would like it to be
swapped out if needed, making room for running processes etc. as
regular VM paging algorithms decide. Of course, if that could be
controlled with a flag we'd both be happy :)

> btw, what linux and opensolaris do when available mem/swap gets low due
> to tmpfs and how filesystem size determined at real-time?

There's some information here: http://en.wikipedia.org/wiki/Tmpfs