Source: Operating Systems: Three Easy Pieces (OSTEP) — Chapter 45, Arpaci-Dusseau & Arpaci-Dusseau

Data Integrity and Protection

RAID assumed fail-stop disks. Real drives also fail partially [P+05]: some blocks become unreadable or silently wrong.

Crux: how do we ensure what we write is what we read later — efficiently?

Disk failure modes

Fault	Symptom	Silent?
Whole-disk	Drive gone	No
Latent sector error (LSE)	Read/write returns an error (ECC can’t fix)	No
Block corruption	Wrong data returned; drive thinks it’s fine	Yes

Over ~1.5M drives / ~3 years [B+07,B+08]: cheap drives ~9.4% had ≥1 LSE, ~0.5% corruption; costly drives ~10× better — still not zero. LSEs show spatial/temporal locality; scrubbing finds most. Corruption varies by model and is not independent across RAID members.

Handling LSEs

Detection is built-in. Recover with existing redundancy: other mirror copy or parity reconstruction.

Rebuild hazard: reconstructing a failed disk while hitting an LSE on a survivor can fail the rebuild. Extra redundancy (e.g. NetApp RAID-DP dual parity) [C+04] covers that case — at space (and some update) cost.

Detecting corruption: checksums

A checksum C(D) is a small summary of block D. Store it with the data; on read compare stored Cs(D) to computed Cc(D).

Function	Notes
XOR	Fast; misses some multi-bit patterns
Addition	Fast; weak on shifts
Fletcher	Two running sums; near-CRC strength, cheap
CRC	Binary modulo by agreed `k`; popular in networking

Collisions are inevitable (large → small). Stronger usually means slower — no free lunch.

Layout: manufacturers may use 520 B sectors (8 B checksum); otherwise pack checksums into full sectors (extra RMW when updating one data block).

On mismatch: use a redundant good copy, or return an error. Checksums detect; they don’t invent correct data.

Quiz

Rank the sequence

1 / 1

Order the steps of checksum-based integrity checking, from write to a later read (top = first).

OrderDrag the handle to rearrange — top should be first.

1Fall back to a redundant copy or return an error
2On read, recompute Cc(D) from the data just read
3Compute C(D) and store it alongside the data on write
4Compare Cs(D) to Cc(D)

Drag items into the correct order (or use ↑↓), then check.

Harder silent faults

Misdirected write — correct payload, wrong LBA/disk. Fix: store physical ID (disk #, offset) with the checksum; verify on read.

Lost write — device claims success; old block remains. Basic C(D) and physical ID still match the old data. Mitigations: read-after-write (2× I/O) or a checksum in a parent structure (ZFS inode/indirect) so orphaned old data fails the upper check.

Scrubbing and overheads

Cold data may never be read by apps → bit rot can kill every copy unnoticed. Scrub periodically (nightly/weekly): read all blocks, verify checksums.

Overhead	Typical
Disk space	~8 B / 4 KB ≈ 0.2%
Memory	Transient unless you keep checksums for RAM protection
CPU	Compute on store + load; often combined with copy
I/O	Extra if checksums live separately; scrub is tunable background

Interactive

Try: fault types · LSE recovery · checksum use · misdirect/lost write · cost.

Check your understanding

Quiz

Data integrity

1 / 6

Compared to fail-stop, the fail-partial model adds…

Pick an answer to see if you are right.

Coding challenges

Homework lab: checksums

Use the OSTEP file-integrity homework (checksum.py + C coding).

Lab

Homework: checksum.py + code

0/3 started

Loading lab…

Summary

Technique	Guards against
RAID / mirrors	LSEs (once detected), disk loss
Checksums	Silent corruption
Physical IDs	Misdirected writes
Parent checksums / verify	Lost writes
Scrubbing	Rot of cold replicas

Previous: Flash-based SSDs

Next: Persistence Dialogue — recap the persistence arc.

Disk failure modes​

Handling LSEs​

Detecting corruption: checksums​

Harder silent faults​

Scrubbing and overheads​

Interactive​

Check your understanding​

Coding challenges​

Homework lab: checksums​