Freeze during early boot

[Mason Loring Bliss]

Hi, all. I'd like to see FreeBSD running on a new class of box I've got
here. Not new hardware. These are Atom chips on Micro-ITX motherboards, and
are interesting in that they are low-power and have dual gigabit NICs.
They're UEFI-only.

These boxes seem to not like the FreeBSD 12.1 .iso files as written to USB
sticks, but I could boot the installer with an .img.

That said, the resulting system as installed seems to freeze in precisely 
the same place as the .iso-files-written-to-USB froze. I took a photo of 
the freeze, and then realized that it was the same as when I was trying to 
boot from the USB stick the first time.

I've got a photo of it in the bug I've just opened to complement this 
email, along with dmesg from NetBSD and Linux:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249226

What's different between the .iso and the .img files, and how might that 
translate to the installed system, if that's not a red herring? And how 
might I get these boxes to boot FreeBSD? 

The boxes don't have build-in storage so I'm installing and booting from 
USB drives, so making modifications from another system to test things 
ought to be fairly straightforward.

Addendum: To try -current in case it was a known issue, I downloaded the 
mini-memstick.img, but it freezes in the same place.

-- 
Mason Loring Blissma...@blisses.org
They also surf, who only stand on waves.


signature.asc
Description: PGP signature

Re: svn commit: r365419 - in head/sys/dev: ath bwi iwm iwn mwl otus usb/wlan wtap

[Tomoaki AOKI]

This breaks at least iwm. (Other drivers not tested.)

Messages below are repeatedly shown and no carrier detected.
Manually reverting this commit fixes the issue.

iwm0: failed to send antennas before calibration: 35
iwm_run_init_ucode: failed 35
iwm_init_hw failed 35
iwm0: could not initiate scan


and lesser times messages below.

iwm0: iwm_send_phy_db_data: Cannot send HCMD of Phy DB cfg section, 35
iwm_init_hw failed 35
iwm0: could not initiate scan


> Author: bz
> Date: Mon Sep  7 15:35:40 2020
> New Revision: 365419
> URL: https://svnweb.freebsd.org/changeset/base/365419
> 
> Log:
>   WiFi: fix ieee80211_media_change() callers
>   
>   In r178354 with the introduction of multi-bss ("vap") support
factoring
>   out started and with r193340 ieee80211_media_change() no longer returned
>  ENETRESET but only 0 or error.
>   As ieee80211(9) tells the ieee80211_media_change() function should not
>   be called directly but is registered with ieee80211_vap_attach()
instead. 
>   Some drivers have not been fully converted.  After fixing the return
>   checking some of these functions were simply wrappers between
>   ieee80211_vap_attach() and ieee80211_media_change(), so remove the
extra
>   function, where possible as well.
>   
>   PR: 248955
>   Submitted by:   Tong Zhang (ztong0001 gmail.com) (original)
>   MFC after:  3 days
>   Sponsored by:   The FreeBSD Foundation
> 
> Modified:
>   head/sys/dev/ath/if_ath.c
>   head/sys/dev/bwi/if_bwi.c
>   head/sys/dev/iwm/if_iwm.c
>   head/sys/dev/iwn/if_iwn.c
>   head/sys/dev/mwl/if_mwl.c
>   head/sys/dev/otus/if_otus.c
>   head/sys/dev/usb/wlan/if_run.c
>   head/sys/dev/wtap/if_wtap.c
> 
> Modified: head/sys/dev/ath/if_ath.c
> ==
> --- head/sys/dev/ath/if_ath.c Mon Sep  7 14:40:33 2020(r365418)
> +++ head/sys/dev/ath/if_ath.c Mon Sep  7 15:35:40 2020(r365419)
> @@ -160,7 +160,6 @@ static intath_init(struct ath_softc *);
>  static void  ath_stop(struct ath_softc *);
>  static int   ath_reset_vap(struct ieee80211vap *, u_long);
>  static int   ath_transmit(struct ieee80211com *, struct mbuf *);
> -static int   ath_media_change(struct ifnet *);
>  static void  ath_watchdog(void *);
>  static void  ath_parent(struct ieee80211com *);
>  static void  ath_fatal_proc(void *, int);

(snip)

> Modified: head/sys/dev/iwm/if_iwm.c
> ==
> --- head/sys/dev/iwm/if_iwm.c Mon Sep  7 14:40:33 2020(r365418)
> +++ head/sys/dev/iwm/if_iwm.c Mon Sep  7 15:35:40 2020(r365419)
> @@ -4426,8 +4426,8 @@ iwm_media_change(struct ifnet *ifp)
>   int error;
>  
>   error = ieee80211_media_change(ifp);
> - if (error != ENETRESET)
> - return error;
> + if (error != 0)
> + return (error);
>  
>   IWM_LOCK(sc);
>   if (ic->ic_nrunning > 0) {
> @@ -4435,7 +4435,7 @@ iwm_media_change(struct ifnet *ifp)
>   iwm_init(sc);
>   }
>   IWM_UNLOCK(sc);
> - return error;
> + return (0);
>  }
>  
>  static void

(snip)
 

-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: vfs.zfs.min_auto_ashift and OpenZFS

[Ryan Moeller]

On 9/9/20 5:40 PM, Slawa Olhovchenkov wrote:

On Wed, Sep 09, 2020 at 11:55:14AM -0400, Ryan Moeller wrote:


On 9/8/20 4:31 PM, Niclas Zeising wrote:

On 2020-05-02 02:20, Matthew Macy wrote:

OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something that needs to be resolved before the code can be
integrated downstream.

So currently all pools created with OpenZFS will use 512 bit
alignment, at least if the underlying storage device uses 512bit
sectors (which most drives tend to do)?

If this is the case, it feels like a pessimisation.

Regards


The vdev ashift optimizations from FreeBSD were put in OpenZFS before
the import into base. That sysctl does work now.

Ugly hack w/ geom_noop required again?



I believe you can do `-o ashift=` with zpool create/add now.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: vfs.zfs.min_auto_ashift and OpenZFS

[Slawa Olhovchenkov]

On Wed, Sep 09, 2020 at 11:55:14AM -0400, Ryan Moeller wrote:

> 
> On 9/8/20 4:31 PM, Niclas Zeising wrote:
> > On 2020-05-02 02:20, Matthew Macy wrote:
> >> OpenZFS doesn't have the same ashift optimization logic that FreeBSD
> >> has. It's something that needs to be resolved before the code can be
> >> integrated downstream.
> >
> > So currently all pools created with OpenZFS will use 512 bit 
> > alignment, at least if the underlying storage device uses 512bit 
> > sectors (which most drives tend to do)?
> >
> > If this is the case, it feels like a pessimisation.
> >
> > Regards
> 
> 
> The vdev ashift optimizations from FreeBSD were put in OpenZFS before 
> the import into base. That sysctl does work now.

Ugly hack w/ geom_noop required again?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: tracking -current, using poudriere-devel and the switch to git

[Ed Maste]

On Wed, 9 Sep 2020 at 15:00, tech-lists  wrote:
>
> Hi,
>
> What's the repo to use now in order to track -current with a poudriere jail
> via git ? i.e. in poudriere.conf, what is GIT_BASEURL ?

svn is still the canonical repo.

If you want to help test the Git migration work in progress, the repos are
https://cgit-beta.freebsd.org/doc.git
https://cgit-beta.freebsd.org/src.git
https://cgit-beta.freebsd.org/ports.git
Branch name is "main"

The hashes in these repos will change at least once more to clean up
some broken metadata from the svn mirror process.

If you want to use Git with repos that will remain consistent (hashes
will not change) for the immediate future, use the GitHub mirror
https://github.com/freebsd/freebsd-doc
https://github.com/freebsd/freebsd
https://github.com/freebsd/freebsd-ports
Branch is "master"

> If -current fails to compile, how do we reference it? In svn, I'd point svn
> info at the sources and it would give a revision number. How is this done with
> git?

>From the rev-parse man page:
| Print the object name of the current commit:
|
| $ git rev-parse --verify HEAD

> At the moment, is svn behind git in terms of most recent updates, or the other
> way round?

Today the canonical src, doc, and ports repos are ahead; GitHub and
cgit-beta are behind to varying degrees.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS and L2ARC

[John Baldwin]

On 9/9/20 1:30 AM, Stefan Esser wrote:
> Am 09.09.20 um 08:46 schrieb Stefan Esser:
>> Am 09.09.20 um 00:45 schrieb Graham Perrin:
>>> Recalling 
>>> ,
>>>  
>>> 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.

A simple fix might be to use CTLFLAG_SKIP so that you only invoke the
expensive sysctls if you request them by name, but not if you request
the 'kstat.zfs' tree.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

tracking -current, using poudriere-devel and the switch to git

[tech-lists]

Hi,

What's the repo to use now in order to track -current with a poudriere jail
via git ? i.e. in poudriere.conf, what is GIT_BASEURL ?

What's the branch name? (is it master, head, something else?)

If -current fails to compile, how do we reference it? In svn, I'd point svn
info at the sources and it would give a revision number. How is this done with
git?

At the moment, is svn behind git in terms of most recent updates, or the other
way round?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: vfs.zfs.min_auto_ashift and OpenZFS

[Niclas Zeising]

On 2020-09-09 17:55, Ryan Moeller wrote:


On 9/8/20 4:31 PM, Niclas Zeising wrote:

On 2020-05-02 02:20, Matthew Macy wrote:

OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something that needs to be resolved before the code can be
integrated downstream.


So currently all pools created with OpenZFS will use 512 bit 
alignment, at least if the underlying storage device uses 512bit 
sectors (which most drives tend to do)?


If this is the case, it feels like a pessimisation.

Regards



The vdev ashift optimizations from FreeBSD were put in OpenZFS before 
the import into base. That sysctl does work now.




Thank you for the clarification!
Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: vfs.zfs.min_auto_ashift and OpenZFS

[Ryan Moeller]

On 9/8/20 4:31 PM, Niclas Zeising wrote:

On 2020-05-02 02:20, Matthew Macy wrote:

OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something that needs to be resolved before the code can be
integrated downstream.


So currently all pools created with OpenZFS will use 512 bit 
alignment, at least if the underlying storage device uses 512bit 
sectors (which most drives tend to do)?


If this is the case, it feels like a pessimisation.

Regards



The vdev ashift optimizations from FreeBSD were put in OpenZFS before 
the import into base. That sysctl does work now.



-Ryan

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Livelock on recent current

[Kevin Oberman]

On Wed, Sep 9, 2020 at 3:01 AM Thomas Mueller  wrote:

> > I am seeing a problem since I moved to current on my laptop this week.
> It's
> > odd as it is linked to the keyboard. As long as the keyboard is active,
> > everything is fine, but if the keyboard is not used, after a few minutes,
> > it locks up and gets very hot. The system may be busy or idle. The system
> > seems completely locked. It does not respond in the network and the
> > display, X or just vt is frozen. The only factor is use of the keyboard.
>
> > I'm not sure what information I might collect.
>
> > The system is a ThinkPad L15 with 4GN of DRAMM (more on order) .
> > FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep  8 20:16:02 PDT 2020
> > root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
> > FreeBSD ptavv 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep  8
> 20:16:02 PDT 2020
> > root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
>  amd64
> > Intel(R) Core(TM) i5-10210U CPU (Crystal Lake)
>
> > Kevin Oberman, Part time kid herder and retired Network Engineer
>
> Overheating, maybe?
>
> I can see CPU temperature with "envstat" (NetBSD) or
> sysctl -a | grep "temperature" (FreeBSD) :
> don't know how Linux does it.
>
> Is there any way you could run
> sysctl -a | grep "temperature"
> at one- or two-minute intervals, perhaps on a different virtual terminal?
>
> I've heard of laptops getting hot, but that was not specifically connected
> to keyboard inactivity.
>
> Tom
>
On FreeBSD on Intel, just load coretemp.ko and it's in
dev.cpu.?.temperature, where ? is the CPU. When running my desktop, I have
it continuously displayed with the gkrellm2 system display. Since it will
fail when the system is idle, I don't think it gets hot until after the
lock-up, but I'll confirm it when I get back to that system later today.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Livelock on recent current

[Jan Kokemüller]

On 09.09.20 06:18, Kevin Oberman wrote:
> I am seeing a problem since I moved to current on my laptop this week. It's
> odd as it is linked to the keyboard. As long as the keyboard is active,
> everything is fine, but if the keyboard is not used, after a few minutes,
> it locks up and gets very hot. The system may be busy or idle. The system
> seems completely locked. It does not respond in the network and the
> display, X or just vt is frozen. The only factor is use of the keyboard.

Reminds me of this bug:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225341

I've been experiencing similar hangs when that timer in atkbd is
enabled. It doesn't seem to happen in the default keyboard
configuration, though.

-Jan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Livelock on recent current

[Thomas Mueller]

> I am seeing a problem since I moved to current on my laptop this week. It's
> odd as it is linked to the keyboard. As long as the keyboard is active,
> everything is fine, but if the keyboard is not used, after a few minutes,
> it locks up and gets very hot. The system may be busy or idle. The system
> seems completely locked. It does not respond in the network and the
> display, X or just vt is frozen. The only factor is use of the keyboard.

> I'm not sure what information I might collect.
 
> The system is a ThinkPad L15 with 4GN of DRAMM (more on order) .
> FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep  8 20:16:02 PDT 2020
> root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
> FreeBSD ptavv 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep  8
20:16:02 PDT 2020
> root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
 amd64
> Intel(R) Core(TM) i5-10210U CPU (Crystal Lake)

> Kevin Oberman, Part time kid herder and retired Network Engineer

Overheating, maybe?

I can see CPU temperature with "envstat" (NetBSD) or
sysctl -a | grep "temperature" (FreeBSD) :
don't know how Linux does it.

Is there any way you could run 
sysctl -a | grep "temperature"
at one- or two-minute intervals, perhaps on a different virtual terminal?

I've heard of laptops getting hot, but that was not specifically connected to 
keyboard inactivity.

Tom

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS and L2ARC

[Stefan Esser]

Am 09.09.20 um 08:46 schrieb Stefan Esser:

Am 09.09.20 um 00:45 schrieb Graham Perrin:
Recalling 
, 
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.


OpenPGP_signature
Description: OpenPGP digital signature

Re: OpenZFS and L2ARC

[Stefan Esser]

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 
, 
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

real0m16,446s
user0m0,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


OpenPGP_signature
Description: OpenPGP digital signature