rob-wing

> 1. Regarding adding `vdev_io_n` and `vdev_io_t` - are we thinking that users will want to configure IOs thresholds independently of checksum thresholds? If not, it might be easier to...

Looks like there are failing tests related to this change, I'll dig into it and see what's going on. I'll update this pull request with review feedback when I get...

@tonyhutter, as requested - I've added a few test cases: - with default settings (checksum_n=10,checksum_t=600), verify that a vdev degrades when 10 checksum events are injected in the span of...

The test I wrote is failing, it looks like either the 'ereport.fs.zfs.checksum' isn't making it to `$ZED_DEBUG_LOG`, the event is not being triggered or it's taking longer than 30 seconds...

What do folks think about storing these properties in the vdev struct? This would allow reading the properties from memory. If I understand correctly, the zap_lookup() in the io pipeline...

> Here's how I would summarize what this PR is proposing: > > Checksum thresholds shouldn't be a per-pool property. Right, allow the user to tune a vdev at a...

It's not super obvious what's failing in the test but, I'm guessing it has something to do with the zap being leaked: ``` 01:47:25.83 MOS object 65 (zap) leaked 01:47:25.83...

There's one thing that concerns me that the root vdev ZAP is not being handled correctly. I've observed that the root vdev ZAP is still leaked when running the `vdev_zaps_007`...

I ended up adding the root vdev ZAP to the AVZ and creating a feature flag, com.klarasystems@avz_v2. I think this approach is cleaner and aligns with the reason why the...

> Please update the man pages to document these new properties (and `root-vdev`). Hey Tony, I documented the new properties in `vdevprops.7`. Would you find it acceptable for the `root-vdev`...