5 ms·
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 sta
by rhinoceraptor 4y ago
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.
- louwrentius 4y agoIf you checksum garbled data from memory, that checksum is useless. Garbage in, garbage out.
- Wowfunhappy 4y agoYes, 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. Checksumming is good.
- rhinoceraptor 4y agoNo one is saying that you shouldn't use ECC, obviously you should if at all possible. But even if you don't have it, that is no reason not to use ZFS.
- Avamander 4y ago> 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.