Matthew Ahrens

In the absence of https://github.com/openzfs/zfs/pull/9175, this is only able to scrub some of the blocks that encountered errors in the previous scrub. If a snapshot was deleted, then any errors...

> zfs diff was found to be extremely slow to the point of being almost unusable. These changes often improve performance 10 - 100x. My understanding is that we would...

cc @pcd1193182 @jjelinek

It looks like you are doing a "blow away" receive, where we are receiving a full (non-incremental) stream on top of a filesystem that already exists (dpool/backups/xyz/jbsnet/latitude/CURRENT/rpool/scratch). In this case,...

If you haven't configured the system to reboot when zfs panic's, you might be able to get the output of `cat /proc/spl/kstat/zfs/dbgmsg` (at least the end of it, starting when...

I think that the panic occurs when destroying the `%recv` dataset (the last line in the dbgmsg). In `dsl_fs_ss_count_adjust()` we have this code, which should be causing it to bail...

You could use bpftrace to print out the stack, `dd_myname` and `prop` when dsl_fs_ss_count_adjust() is called.

The originally-reported issue should have been resolved by https://github.com/openzfs/zfs/pull/10791, which is fixed in 2.0. It's possible that if your filesystem (data/myhost-main/data/backupdata/veeam/repos/repo_01_old) was created on an earlier release, you could still...

If you can remove the VERIFY and compile from source, the destroy might "just work" and not introduce any more problems.

For slightly more background info, I talked about this project briefly on the [April video call](https://www.youtube.com/watch?v=6zb6AxL26d8&t=2128s).