Checksums detect disagreement; redundancy supplies a repair source

A checksum is computed over a defined sequence of bytes and compared with an expected value when those bytes are read or inspected. Btrfs normally checksums data and metadata, with data checksums stored separately from their data blocks. Other filesystems may checksum selected metadata without providing the same coverage for ordinary file payload. Always inspect the feature and file settings involved. A statement that a filesystem uses checksums is incomplete until you know which objects, paths, and modes are covered by the protection being claimed.

A mismatch establishes disagreement, not the complete cause. The payload may be damaged, the stored checksum may be damaged, or an addressing or version error may have paired the wrong objects. A successful comparison is also not proof against an attacker who can replace both data and an unprotected expected checksum. Authentication requires an appropriate trusted digest, signature, or message-authentication scheme and a trust chain. For model releases, binding the content digest to a trusted manifest and generation can address questions that a block-level accidental-error check was never designed to answer.

If only one damaged copy exists, a checksum can tell you that recovery is needed without containing enough information to reconstruct the missing contents. Redundant data, parity under its stated assumptions, or an independent backup can supply repair candidates. The system must verify the candidate rather than blindly copy from the first responding device. Redundancy that shares a failure source may reproduce the same corruption everywhere. Distinguish multiple names, multiple physical copies, multiple devices, and independently administered backups; they provide different protection against different events.

Scrubbing proactively reads allocated content to find latent problems before an ordinary application happens to touch it. Btrfs scrub can verify checksummed data and metadata and, when a valid redundant copy is available under the selected profile, repair from that copy. It is not a general filesystem structural checker or a substitute for backups. Scheduling matters: scrub consumes bandwidth and must finish often enough for the intended detection window. Monitor detected, corrected, and uncorrectable errors separately, and keep evidence that a repair candidate actually passed its check.

Suppose a block is damaged shortly after a scrub. It can remain latent until a later scrub or application read detects it. A second failure during that interval can eliminate the good copy the repair plan assumed. Shorter detection intervals reduce this particular exposure but cost I/O; they do not remove software bugs, common power events, or malicious deletion. Build a threat and fault model first, then assign each mechanism a role. Restore tests are needed because possessing a backup and reconstructing a usable application state are different accomplishments.

The binomial lab models independent trials with failure probability p and trial count n. Before changing n, predict that the expected affected count scales as np; before increasing p, predict probability mass shifting toward more failures. This is useful for understanding why scanning more independently exposed blocks finds more events in a simplified model. It cannot estimate a drive's real failure probability, reproduce checksum collisions, or model correlated firmware faults. Explain which shared causes would invalidate independence before applying the arithmetic to redundant copies.