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

[Attila Nagy]

On 01/30/11 12:09, Kostik Belousov wrote:
> 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.
>
Well, if nobody can take care of this now, could you please state this 
in the BUGS section of the tmpfs man page?

Thanks,