Alexander Motin

> Can you also look in to the `ztest` failure, this PR seems to reliably cause it to fail. @robn I've asked @ixhamza to take a look at this, and...

Not saying anything about py-SMART, but smartctl has been known for using bridge specific commands to access SMART data behind USB bridges. There is no NVMe to SCSI command pass-through...

On Core we are building alternative version of ZFS via ports instead of the bundled OS one. So while this PR looks OK to me, it should be merged only...

I don't have any quick ideas, but at some point Brian noticed FreeBSD CI failures with supposedly some kernel panic after tests completion, possibly on module unload. With some hope...

I hoped for something more specific/synthetic, like a CI test. I'll think about it.

@markjdb Thank you for the reproduction, it works. Addition of `arc_buf_destroy(db->db_buf, db);` into `dmu_buf_fill_done()` seems to fix the assertion, but I'll look deeper tomorrow to be sure.

> but does not fix the title of the ticket. `panic: VERIFY3(rc->rc_count == number) failed ` can still be triggered reliably. @lundman Are you talking about failmode=continue, or you have...

This assertion IS about memory leaks. The fact that you see it in othet scenarios just means there are other leaks, probably unrelated to the one I fixed.

One of our customers just hit this problem with billions of files in a wild. It would be good to merge this patch (may be without removal of the macros...

> It's already queued up in the staging branch for 2.2.5, #16186. Thanks. I've already noticed that. > That version does drop the macros, is there some other known consumer...