is TMPFS still highly experimental?

[Attila Nagy]

  On 10/03/2011 08:42 PM, Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 10/03/11 11:36, Attila Nagy wrote:
>> On 10/03/2011 07:14 PM, Xin LI wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> Hi, Attila,
>>>
>>> On 10/03/11 04:29, Attila Nagy wrote:
>>>> For me, the bug is still here: $ uname -a FreeBSD b 8.2-STABLE
>>>> FreeBSD 8.2-STABLE #5: Wed Sep 14 15:01:25 CEST 2011
>>>> root at buildervm:/data/usr/obj/data/usr/src/sys/BOOTCLNT  amd64 $
>>>> df -h /tmp Filesystem    Size    Used   Avail Capacity  Mounted
>>>> on tmpfs           0B      0B      0B   100%    /tmp
>>>>
>>>> I have no swap configured. The machine has 64 GB RAM.
>>>> vm.kmem_size=60G; vfs.zfs.arc_max=55G; vfs.zfs.arc_min=20G
>>> This sounds like a configuration issue.  Running without swap is
>>> not recommended anyways.
>> I guess it depends on the workload. In general, you are possibly
>> right, but if you need predictable response times and you can
>> tolerate dying processes, swapping may not be the right thing to
>> do.
> Well, in that case one will have to tolerate tmpfs have no page to
> allocate (note that it does need to reserve some pages for system use)
> at this point.  Currently it's working like a credit line -- use it
> here and you can't use it elsewhere, e.g. if user process used it then
> tmpfs can't use it...
Sure, but we are talking here about ARC, which is a cache. I guess tmpfs 
work quite OK with UFS, where it will shrink its cache space.
BTW, I don't care if tmpfs shows 2 GB free space when there is (>)2 GB, 
but currently I have:
Mem: 564M Active, 3091M Inact, 55G Wired, 129M Cache, 71M Buf, 2957M Free
and:
Filesystem    Size    Used   Avail Capacity  Mounted on
tmpfs           0B      0B      0B   100%    /tmp
That's the first problem.
(the second could be to shrink ARC from tmpfs-land if needed)
> I think the only solution we can have here is to teach tmpfs about
> "dedicated reserve for tmpfs" so it pre-allocate a few pages that can
> not be reused elsewhere?  E.g. create a budget that make this part of
> memory "tmpfs fund" :)
>
>
There is md for that. Sure, it's harder, and using UFS (or any other FS) 
on md seems to be a waste of resources.

For me it would be quite enough if tmpfs wouldn't loose all its space 
when there is free memory.