Regardless, it's still frustrating that so many failure modes for ZFS have an answer of "blow it all away and start again". And that's with Solaris/ZFS.

There are other ways to fix issues with ZFS pools without having to "blow it all away and start again". In the example that started this conversation fork, there's a simple parameter to pass to the zpool utility that would have saved the OP from dropping his pool:

    zpool clear tank

ZFS does actually come with a decent set of tools for fixing and clearing faults - which I'm starting to realise isn't as widely known (possibly because people rarely run into a situation where they need it?)

Anecdotally speaking; I've ran the same pool for years on consumer hardware and that pool has even survived a failing SATA controller that was randomly dropping disks during heavy IO and causing kernel panics. So I've lost count of the number times ZFS has saved my storage pool from complete data loss where other file systems would have just given up.

Indeed, however that's all dropping and recreating the pool would do as well. The file would still be corrupt.

I agree completely. Much better to know than not. But having no option to knowingly just lose inconsistent data and move on is a bummer.

A corrupt file in ZFS indicates multiple broken disks. Copy the file in from a backup, use raidz3 and/or set copies=2 for critical zfs volumes. https://blogs.oracle.com/relling/entry/zfs_copies_and_data_p...