Re: OpenZFS and L2ARC

Am 09.09.20 um 08:46 schrieb Stefan Esser:
> Am 09.09.20 um 00:45 schrieb Graham Perrin:
>> 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 ...

Update: I have created a fork of zfs-stats to work on:

https://github.com/stesser/zfs-stats

Initial change is to work around the long delay mentioned above and to
use the correct name for the vdev cache size variable and to display
the size, data contents and the corresponding compression factor of the
compressed L2ARC.

I'll create pull requests to inform the upstream of these changes.