Re: zfs pool behavior - is it ever freed?

[Greg Troxel <gdt%lexort.com@localhost>]

Tobias Nygren <tnn%NetBSD.org@localhost> writes:

> n Thu, 27 Jul 2023 06:43:45 -0400
> Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>>   Thus it seems there is a limit for zfs usage, but it is simply
>>   sometimes too high depending on available RAM.
>
> I use this patch on my RPi4, which I feel improves things.
> People might find it helpful.
> There ought to be writable sysctl knobs for some of the ZFS
> tuneables, but looks like it isn't implemented in NetBSD yet.

It definitely helps.

The upstream code tries to find a min/target/max under the assumption
that there is a mechanism to free memory under pressure -- which there
is not.

Reading the code, the cache is supposed to free things if size >
target.  I am not sure that works.   It makes sense to have a target/max
gap so that the freee can be async.  That's often lost.

The code to set min/target/max does not seem clearly sensible to me.
It seems to set arc_max to all RAM except 1 GB.  No wonder we have trouble.

Looking at kstats, I see excessive meta usage, way above limit.  In his
case min/max are historical, not controls.

Here, meta imit is 200M, which is 1/4 of the 800M target for the whole
cache (1/8 of 6GB, my allocation to dom0).  That seems reasonable.
But there is 1.2G of metadata.  Perhaps that is uncompresed size.


kstat.zfs.misc.arcstats.arc_meta_used = 1225255744
kstat.zfs.misc.arcstats.arc_meta_limit = 201326592
kstat.zfs.misc.arcstats.arc_meta_max = 1407252032
kstat.zfs.misc.arcstats.arc_meta_min = 100663296