One of the things that makes ZFS deduplication so dangerous and so infuriating is that it is terribly documented. My example today is what should be a simple question: does turning ZFS deduplication on irreversibly taint the pool and/or filesystem(s) involved such that you'll have performance issues even if you deleted all data, or can you later turn ZFS deduplication off and return the pool to its pre-dedup state of good performance with enough work?

You can find sources on the Internet that will give you both answers. Oracle's own online documentation is cheerfully silent about this (at least the full documentation does contain warnings about the downsides of dedup, although the zfs(1) manpage still doesn't). The only way to know for sure is to either read kernel source or find a serious ZFS expert and ask them.

(I don't know the answer, although I'd like to.)

This should not be how you find answers to important questions about ZFS dedup. That it is demonstrates how bad the ZFS dedup documentation is, both the official Oracle documentation and most especially the Illumos manpages (because with Illumos, the manpages are mostly it).

By the way, I'm picking on ZFS dedup because ZFS dedup is both a really attractive sounding feature (who doesn't want space savings basically for free, or at least what sounds like free) and probably the single biggest way to have a terrible experience with ZFS. The current state of affairs virtually guarantees a never-ending stream of people blowing their feet off with it and leaving angry.

(The specific question here is very important if you find that dedup is causing you problems. The answer is the difference between having a reasonably graceful and gradual way out or finding yourself facing a potentially major dislocation. And if there is a graceful way out then it's much safer to experiment with dedup.)