Alan Somers

Update: I've identified the root cause of the bug. The process is running into a thread limit. In my test setup, I could conceivably need 3079 threads to fully populate...

> Direct execution may not work if different threads are used to decouple locks or some other resource. My only other ideas aren't perfect either: * Use a delay loop...

What about removing all of the histogram stuff from the event, but adding a custom dtrace probe to get it? If checksum events are rare, then the histogram probably won't...

Yes, it's a fixed size, so increasing it for one event increases it for all. And it's already pretty big, compared to what most events need (usually fewer than 200...

No, because that PR was only a partial solution. The messages are still too long.

@rincebrain this is still a problem. Would you be open to adding an off-by-default sysctl knob, something like `vfs.zfs.checksum_event_verbose`? When off, ZFS would omit the checksum histograms.

Great! I'll create a PR to remove the histogram fields. However, I now realize there's another problem too. For disks that aren't in RAIDZ arrays, ZFS adds a few other...

We also suffer from this bug, but the following patch fixes it: ```diff diff --git a/sysutils/py-salt/files/patch-salt_ext_tornado_iostream.py b/sysutils/py-salt/files/patch-salt_ext_tornado_iostream.py new file mode 100644 index 000000000000..56792d9c098e --- /dev/null +++ b/sysutils/py-salt/files/patch-salt_ext_tornado_iostream.py @@ -0,0 +1,10...

I agree that it's not a perfect solution.

Regarding NETLINK_GENERIC, ask @GuillaumeGomez . He's the one who added the definition from if_mib.h . Also, grep.app shows that his sysinfo crate is the only one that's using it as...