It's just not true that if ZFS metadata is corrupted, then the entire pool is gone. ZFS is a transactional file system, so the pool will be put in a faulted state, and it gives you the option to roll back to before the faulty transaction.
I really do not see how anyone could possibly think that is worse than your data being silently corrupted on disk, which then propagates to your backups, corrupting them too.
People seem to think ZFS is worse because it tells you when your data is corrupted, rather than not telling you? It doesn't make any sense.
> It's just not true that if ZFS metadata is corrupted, then the entire pool is gone. ZFS is a transactional file system, so the pool will be put in a faulted state, and it gives you the option to roll back to before the faulty transaction.
It is true because ZFS on Linux crashes very quickly when metadata is corrupt. It can't roll back transactions because it'll crash almost instantly even looking at your pool, not to mention when scrubbing it.
Yes, the checksum is useless, because the checksummed file is corrupt. By contrast, without checksumming... the file would still be corrupt!
In the best case, when good data was written to disk, checksumming preserves the good data. In the worst case, when bad data was written to disk, checksumming does no harm.
I really do not see how anyone could possibly think that is worse than your data being silently corrupted on disk, which then propagates to your backups, corrupting them too.
People seem to think ZFS is worse because it tells you when your data is corrupted, rather than not telling you? It doesn't make any sense.