Brian Behlendorf

@ryao since e949d360 was only recently merged, and comparatively lightly tested, let's hold off on including it in this release. We can consider adding it to a future point release.

Depending on your hardware this could be normal. Those read I/O latencies are high, but the HDDs may be prioritizing writes when there are only infrequent reads. It's hard to...

There may not be any application reads, but internally ZFS may need to read some data if it's not cached. It looks like the HDDs may be slow to service...

Either bisecting or employing the [kernel stack tracer](https://jasoncc.github.io/kernel/ftrace-stack-tracer.html) would be the best way to run where we're stack heavy. Clearly the recursive `dmu_objset_find_dp_impl()` calls are concerning (and a good place...

Setting up Minicloud to verify the build seems like it would be a nice option, particularly since our current ppc64 builder is ancient. We'd probably only be able to do...

Yeah, that wasn't entirely clear to me. Still we run in to trouble the first time we panic the kernel unless we have programmatic to cleanup the mess.

That's interesting, I guess I always assumed that wouldn't be a viable option. But if we can reliably reboot after an panic and then clean things up on boot, perhaps...

If the directory is damaged, as indicated by the checksum error, then it cannot be safely removed without leaking the disk space used by the files in that directory. This...

I've only recently started seeing this occasional test failure in the logs, so that's a reasonable guess. Normally, we only track failures observed in the last 30 days, that can...

Until this is resolved, we may want to add this test to our know list of flakey tests in `tests/test-runner/bin/zts-report.py.in`.