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

[Kostik Belousov]

On Wed, Jan 19, 2011 at 05:27:38PM +0100, Ivan Voras wrote:
> On 19 January 2011 16:02, Kostik Belousov <kostikbel at gmail.com> wrote:
> 
> >> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch
> >>
> >> I don't think this is a complete solution but it's a start. If you can,
> >> try it and see if it helps.
> > This is not a start, and actually a step in the wrong direction.
> > Tmpfs is wrong now, but the patch would make the wrongness even bigger.
> >
> > Issue is that the current tmpfs calculation should not depend on the
> > length of the inactive queue or the amount of free pages. This data only
> > measures  the pressure on the pagedaemon, and has absolutely no relation
> > to the amount of data that can be put into anonymous objects before the
> > system comes out of swap.
> >
> > vm_lowmem handler is invoked in two situations:
> > - when KVA cannot satisfy the request for the space allocation;
> > - when pagedaemon have to start the scan.
> > None of the situations has any direct correlation with the fact that
> > tmpfs needs to check, that is "Is there enough swap to keep all my
> > future anonymous memory requests ?".
> >
> > Might be, swap reservation numbers can be useful to the tmpfs reporting.
> > Also might be, tmpfs should reserve the swap explicitely on start, instead
> > of making attempts to guess how much can be allocated at random moment.
> 
> Thank you for your explanation! I'm still not very familiar with VM
> and VFS. Could you also read my report at
> http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html
> ? I'm curious about the fact that there is lots of 'free' memory here
> in the same situation.
This is another ugliness in the dynamic calculation. Your wired is around
15GB, that is always greater then available swap + free + inactive.
As result, tmpfs_mem_info() always returns 0.
In this situation TMPFS_PAGES_MAX() seems to return negative value, and
then TMPFS_PAGES_AVAIL() clamps at 0.

> 
> Do you think that there is something which can be done as a band-aid
> without a major modification to tmpfs?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110130/6f21744c/attachment.pgp