reševanje zfs pool-a

To distill down some cold hard facts come to a fairly inescapable conclusion.

1. ZFS doesn't have a "fsck" for many of the same reasons that ZFS has no recovery tools. When properly managed ZFS should be impossible to corrupt without seriously bad hardware and/or extremely poor administration. ZFS's structures, because of how they are engineered, are one of those things that "work or don't work". If you know they "don't work" because the pool is unmountable, how do you handle the recovery?
2. When a pool becomes corrupted you are often left with a situation where you have to trust data on diskA or data on diskB since they don't agree. That's a decision that is really hard (if not impossible) to accurately master in code.
3. ZFS is marketed for enterprises. You know, companies that can add an extra zero to cost of the server and not care. These are also the same places where backups are done religiously and all the time and recovery isn't something that a company is going to need, let alone want. Restoring from backups is going to be faster and better for a whole list of reasons
4. Feature flags. These are a mess to deal with as every OS is implementing them differently. While the actual structures on-disk should be the same be it Illuminos or FreeBSD, how they "get there" is often quite different. Sometimes, these peculiarities are important for recovery.

Put all this together and you have a perfect storm of reasons why ZFS recovery is very difficult to "just do" and isn't particularly profitable. No money and low demand means no product will come to market.