- ZFS stores everything in a hash tree, so integrity of all nodes can be verified with the assumption that no hash collision has occurred. 256-bit (SHA256) hashes are used, so it is unlikely that a single collision will ever happen across all systems on which ZFS is deployed for the duration of the universe.
- ZFS stores metadata twice via "ditto blocks". It makes an effort to write metadata at least 1/8 of the disk apart, so random corruption will have to take out two of the same metadata block before it can damage a filesystem.
- ZFS utilizes copy on write to implement atomic transactions, which involve a two stage transaction commit. This involves the disk labels, which store 4 copies of the uberblock. The uberblock is ZFS' equivalent of a superblock Two labels are located at the beginning of the disk and two labels are located at the end of the disk. A transaction commit will first update labels 0 and 2 and then labels 1 and 3, which ensures atomicity.
- ZFS maintains history of the last N uberblocks, which permits rollback to an older entry should malfunctioning hardware cause a write to become inconsistent.
- ZFS recycles blocks only after a certain number of transactions have occurred, so rollback is guaranteed to be possible.
btrfs cannot really compare to this. My understanding of btrfs is somewhat superficial, but lets compare:
- btrfs' uses hashes as well, but it has 32-bit hashes on 32-bit userlands and 64-bit hashes on 64-bit userlands. As long as there are no collisions, you can verify the integrity of data, but the probability of a collision is quite high, especially in the 32-bit case.
- btrfs has no ditto blocks, so if metadata is corrupted, there is a strong possibility that it will be unable to recover.
- btrfs does attempt atomic transactions, but it is single stage. In SSD mode, it only stores a single copy of the superblock. If the primary superblock becomes corrupted, the kernel will no longer recognize it.
- btrfs does not maintain much of a history. It has two pointers. One for the last transaction and one for its predecessor. If malfunctioning hardware corrupts the last two transactions (due to incomplete flushes), btrfs cannot recover.
- btrfs does no automated rebalancing, so rollback is probably possible on it. However, if you do a rebalance, I do not know if it will be possible to do rollback.
Feel free to post corrections. I admit that my knowledge of btrfs is somewhat lacking, but I believe that what I have said is accurate.
You can put your hands over your ears and hum all you want, but the bottom line is that btrfs is untrustworthy.
You do not like btrfs. Fine. Why get into this argument?
Is that somehow supposed to be worse than misquoting me by leaving out multiple words before and after a phrase? LOLAnother difference is that you misquoted me by leaving out a word in the middle of a phrase.
Yeah, I get it. You're going to keep trolling by repeating the same line over and over until everyone gets tired. I once employed the same tactic against Qaridarium. It was pretty glorious.You can put your hands over your ears and hum all you want, but the bottom line is that btrfs is untrustworthy.