What do ZFS and btrfs checksum counters catch that SMART cannot see, and where do they stop?

The answer. A checksum counter is the only signal in these sources that catches data the drive handed back as a good read. The Wisconsin authors define disk corruption as exactly that case, distinct from latent sector errors and other conditions where the drive gives an explicit notification, and OpenZFS defines a checksum error the same way: data expected to be correct that was not, which it calls silent data corruption. SMART attributes and the ATA error log only record what the drive itself noticed, so by construction they cannot count this case.

The reverse also holds, and the published log shows it. When the drive refuses writes instead of returning wrong data, the filesystem checksum counter can stay at zero. In issue 10214 the WRITE counter reached 47.7 K while CKSUM stayed 0, SMART said PASSED, and only the ATA error log (7,487 errors) and the kernel log carried the fault. So a monitoring set built on CKSUM alone would have missed this failure, and one built on SMART overall health alone would have missed it too. This is one drive and one user, and a later comment in the same thread shows nonzero CKSUM next to WRITE errors, so read it as an example of two independent signals, not a rule.

Where a checksum is attached matters more than whether one exists. ZFS stores each block's checksum in its parent block pointer, so a lost or misdirected write is caught on read, and in the paper's fault injection every on-disk corruption was detected and no bad data was returned. But in memory the same design lets bad data through: the checksum is not rechecked for cached blocks, and a flip before flush gets a fresh valid checksum. The measured chance that one flipped bit leads to a corrupt read ranged from 0.6% (varmail) to 7.1% (fileserver) in that setup. The paper also notes that, from the software side, a corrupt block read from disk may not be distinguishable from memory corruption.

Detection is not repair, and neither is attribution. With one copy, ZFS reports the error and cannot fix it; with redundancy it repairs from a good copy. OpenZFS says that if a block cannot be reconstructed, checksum errors are reported for all the disks it sits on, so the per-disk CKSUM count points at a set of suspects, not the culprit. btrfs adds a scrub status that separates Corrected from Uncorrectable errors, and its scrub exit status 3 means uncorrectable errors were found.

Coverage is also bounded by what gets read. Both scrub manual pages describe scrub as the pass that verifies checksums over the data, and the btrfs page says to run it periodically, with about one month recommended. Data nobody reads and nobody scrubs is not verified. btrfs has one explicit hole: NOCOW files carry no data checksums, and the manual page notes that systemd journals and libvirt storage directories commonly set that attribute. For triage, treat filesystem checksum counters as one of three layers next to the drive's SMART and error logs and the SCSI sense and kernel log, because each sees faults the others do not.