Re: OpenZFS and L2ARC

Am 09.09.20 um 00:45 schrieb Graham Perrin:
> On 08/09/2020 08:43, Stefan Esser wrote:
>> OpenZFS seems to work quite well for me, in general, but I have 
>> questions regarding the L2ARC statistics.
>>
> …
> 
>> The sysutils/zfs-stats port reports the following values for
>> this system, BTW:
>>
>> ------------------------------------------------------------------------
>> ZFS Subsystem Report                Tue Sep  8 09:02:46 2020
>> ------------------------------------------------------------------------
>>
> …
> 
>>
>> Quite a number of sysctl variable names have changed, and the port
>> needs to be adapted to the new names (therefore there are lots of 0
>> values in the -L output).
>>
>> The following names used by zfs-stats do not exist in OpenZFS:
>>
>> kstat.zfs.misc.arcstats.recycle_miss
>> kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned
>> kstat.zfs.misc.arcstats.l2_write_buffer_iter
>> kstat.zfs.misc.arcstats.l2_write_buffer_list_iter
>> kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter
>> kstat.zfs.misc.arcstats.l2_write_full
>> kstat.zfs.misc.arcstats.l2_write_in_l2
>> kstat.zfs.misc.arcstats.l2_write_io_in_progress
>> kstat.zfs.misc.arcstats.l2_write_not_cacheable
>> kstat.zfs.misc.arcstats.l2_write_passed_headroom
>> kstat.zfs.misc.arcstats.l2_write_pios
>> kstat.zfs.misc.arcstats.l2_write_spa_mismatch
>> kstat.zfs.misc.arcstats.l2_write_trylock_fail
>> kstat.zfs.misc.arcstats.l2_writes_hdr_miss
>> vfs.zfs.vdev.cache.size
>>
>> The existence of vfs.zfs.vdev.cache.size vs vfs.zfs.vdev.cache_size
>> can be used to detect OpenZFS, and is easily fixed.
>>
>> But the above listed L2ARC values seem to have been removed from or
>> have never existed in OpenZFS, and I did not find any substitutes.
>>
>> Are there any plans to re-create them in OpenZFS on FreeBSD or are
>> they gone for good?
> 
> Recalling 
> <https://lists.freebsd.org/pipermail/freebsd-current/2020-March/075661.html>, 
> on 28/03/2020 15:17,28/03/2020 15:17, Allan Jude wrote:
> 
>  >> …
>  >>
>  >> Basically 'arc' was converted to a subtree.
>  >>
>  >> We should add some backwards compat sysctls to cover some of
>  >> these renames etc so configs and scripts don't break etc.

This is not possible for quite a number of sysctls, since there is
no simple 1:1 mapping for many of them.


And there is an annoyance that I had noticed before but now have
tracked down:

$ time sysctl kstat.zfs.misc.dbufs | wc
    55327 2047031 16333472

real	0m16,446s
user	0m0,055s
sys	0m16,397s

Somebody decided to put a complete list of dbufs under this sysctl
and thus querying "kstat.zfs.misc" takes that long (16 seconds to
generate 16 MB of output on my system), even if only a few other
values in "kstat.zfs.misc" are needed.

I do not know whether there is any chance to get that debug output
moved out of the "misc", e.g. into a new "debug" sub-tree. I'm afraid,
that on Linux there are scripts that expect it under this name.

If it is not acceptable to the upstream, we should locally modify the
sysctl tree to move that variable out of "misc", IMHO. (While not
taking much time, "kstat.zfs.misc.dbgmsg" should also be relocted to
a "debug" sub-tree, IMHO ...)

zfs-stats needs tens of values from "misc", and if they are not all
added individually to the Kstat array, this will limit the response
time to any zfs-stats invocation.

It is not too hard to add the new variables in zfs-stats and to
adapt the calculations to derive meaningful values to display.

But if it always takes 16 seconds to generate any output, I'm not
likely to use it too often ...

Regards, STefan