tmpfs runs out of space on 8.2pre-release, zfs related?

miyamoto moesasji miyamoto.31b at gmail.com
Sun Jan 2 15:50:21 UTC 2011


On Sun, Jan 2, 2011 at 3:26 PM, Ronald Klop <ronald-freebsd8 at klop.yi.org> wrote:
> On Sun, 02 Jan 2011 09:41:04 +0100, miyamoto moesasji
> <miyamoto.31b at gmail.com> wrote:
>
>> miyamoto moesasji <miyamoto.31b <at> gmail.com> writes:
>>
>>>
>>> In setting up tmpfs (so not tmpmfs) on a machine that is using
>>> zfs(v15, zfs v4) on 8.2prerelease I run out of space on the tmpfs when
>>> copying a file of ~4.6 GB file from the zfs-filesystem to the memory
>>> disk. This machine has 8GB of memory backed by swap on the harddisk,
>>> so I expected the file to copy to memory without problems.
>>>
>>
>> ....this is in fact worse than I first thought. After leaving the
>> machine running overnight the tmpfs is reduced to a size of 4K, which
>> shows that tmpfs is in fact
>> completely unusable for me. See the output of df:
>> ---
>> hge at PulsarX4:~/ > df -hi /tmp
>> Filesystem    Size    Used   Avail Capacity iused ifree %iused  Mounted on
>> tmpfs         4.0K    4.0K      0B   100%      18     0  100%   /tmp
>> ---
>>
>> Relevant zfs-stats info:
>> ---
>> System Memory Statistics:
>>        Physical Memory:                        8161.74M
>>        Kernel Memory:                          4117.40M
>>        DATA:                           99.29%  4088.07M
>>        TEXT:                           0.71%   29.33M
>>
>> ARC Size:
>>        Current Size (arcsize):         63.58%  4370.60M
>>        Target Size (Adaptive, c):      100.00% 6874.44M
>>        Min Size (Hard Limit, c_min):   12.50%  859.31M
>>        Max Size (High Water, c_max):   ~8:1    6874.44M
>> ---
>>
>> I'm not sure what triggered this further reduction in size; but the
>> above 4K size is probably important to show how dramatic this goes
>> wrong.
>
> Is it possible that some program is filling a file (on your tmpfs) which is
> deleted?
> You will not see it with df or ls, but it still takes space on the fs, until
> the application closes the file.
>
> Ronald.
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>

I'm pretty sure that this is not the case as the problem shows up
immediately upon a clean reboot (and /tmp is normally pretty empty
with just 22k in use at the moment with the older tmpmfs (determined
with du -xh /tmp as root) )

Note that the key problem was given in the first post. There I posted
that the tmpfs has 8.2GB available immediately after a reboot, yet it
is impossible to copy a 4.6GB file to tmpfs from a zfs-drive even
though the machine has 8GB of memory backed with swap.

My feeling is that somehow the zfs file cache, which is also in memory
is causing this, which is consistent with the solaris bugreport I
linked to, see:
http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=e4ae9c32983000ef651e38edbba1?bug_id=6804661


More information about the freebsd-stable mailing list