Re: ZFS tunable parameters

[Simon Burge <simonb%NetBSD.org@localhost>]

Simon Burge wrote:

> Hi Sotiris,
>
> Sotiris Lamprinidis wrote:
>
> > I looked into exposing ZFS tunables through sysctl and it seems
> > straightforward. Despite being under "dist" I am not sure if this is true 
> > upstream, so the patch is directly on arc.c (and I think it'd be tricky to
> > implement otherwise).
> >
> > I tested arc_min and arc_max, and it seems like changes do have an effect
> > (e.g. on c, c_max). Additionally tested arc_free_target and it does have
> > an effect also.
> >
> > Here are the new sysctl values on boot on a 8G system:
> >
> >     vfs.zfs.arc_min = 392903680
> >     vfs.zfs.arc_max = 3143229440
> >     vfs.zfs.arc_average_blocksize = 8192
> >     vfs.zfs.arc_shrink_shift = 7
> >     vfs.zfs.compressed_arc_enable = 1
> >     vfs.zfs.arc_meta_limit = 785807360
> >     vfs.zfs.arc_meta_min = 0
> >     vfs.zfs.arc_free_target = 682
>
> A FreeBSD 13 VM shows these sysctls:
>
>    vfs.zfs.arc_max: 0
>    vfs.zfs.arc_min: 0
>    vfs.zfs.arc.average_blocksize: 8192
>    vfs.zfs.arc.shrink_shift: 0
>    vfs.zfs.compressed_arc_enabled: 1
>    vfs.zfs.arc.meta_limit: 0               (different name - arc.meta.XXX)
>    vfs.zfs.arc.meta_min: 0                 (different name - arc.meta.XXX)
>    vfs.zfs.arc_free_target: 5285
>
> One day we'll sync up with FreeBSD/OpenZFS, but in the meantime I
> think it's ok to add more knobs that match the current FreeBSD names.
> Michael's patch from a follow-up reply introduces a vfs.zfs_arc which is
> different again.
>
> At first glance, all the extra #ifdef stuff looks a little messy; I
> don't know if that can be somehow done cleaner?

Thanks Sotiris and Michael for those patches!

My attempt to combine both patches as well as synchronise the sysctl
names with those in FreeBSD (for when/if we ever sync with OpenZFS) is
at https://www.NetBSD.org/~simonb/zfs-arc-20260716.diff .  It seemed
cleaner to duplicate the functions rather than add all the extra #ifdef.

One annoying nit is that UVM initialises uvmexp.freetarg very late in
the boot, well after any pre-loaded modules are initialised.  I'm not
sure of a cleaner way of handling this than the current re-check if
zfs_arc_free_target is still 0 in arc_available_memory().

Cheers,
Simon.