What is a torn page, why can a crash while the engine is flushing an 8 KB or 16 KB page produce one, and how do storage engines protect against it - for example with full-page images in the log or a doublewrite area?

## Where the tear comes from Databases work in pages of 4, 8, or 16 KB. Storage devices guarantee atomicity only at a much smaller granularity: classically a 512-byte sector, 4 KB on modern drives, and the guarantee stops at the device anyway - a filesystem, a RAID layer, or a virtualized disk can split or reorder pieces. Writing one 8 KB page is therefore a multi-part operation with no all-or-nothing promise. If the machine loses power or panics partway through, the page on disk becomes a hybrid: some sectors carry the new contents, some the old. This is a **torn page** (also called a partial page write or fractured block). ## Why a torn page is worse than an old page An *old* page is harmless. Recovery expects that - it compares the page's stored log sequence number with the log records and replays the missing changes. The whole redo design assumes the page is some valid version of itself. A torn page is not a valid version. A page has internal structure - a header with a free-space pointer and a log sequence number, an array of item pointers, and the tuples themselves - and those parts can now come from different generations. The header may claim a layout the body does not have; an item pointer can address a region containing something else. The engine may even read a plausible-looking log sequence number from a stale header and conclude the page is up to date, skipping the redo that would have rewritten the damaged half. Silent corruption, discovered days later, is the realistic outcome. Checksums help detect this but do not repair it. ## Why checkpoints are the natural place to discuss it Tearing happens when a page is written to its home location, and the checkpoint mechanism is what schedules the bulk of those writes. More importantly, the standard protection is anchored on checkpoints, as the next section shows: 'the first modification after a checkpoint' is the trigger, which makes checkpoint frequency directly control the protection's cost. ## Protection 1: full-page images in the log The idea: instead of relying on the home-location write being atomic, put a complete, known-good copy of the page somewhere that *is* safe - the log, which is written sequentially and protected by its own checksums. The rule is: **the first time a page is modified after a checkpoint, write its entire image into the log** rather than just the delta. Subsequent modifications of the same page before the next checkpoint log only deltas. Recovery then does something stronger than replay: when it encounters a full-page image, it *overwrites* the on-disk page with that image, no questions asked, without consulting the possibly-garbage header. Whatever tearing had occurred is obliterated, and replay continues from a known state. The cost is log volume. The first touch of a page after each checkpoint costs a full page in the log instead of a few dozen bytes. On a workload that scatters small updates across many pages, this can multiply log write volume several-fold - and it is why **checkpointing more frequently makes the log bigger**, which is counterintuitive until you see the mechanism: each new checkpoint resets every page to 'first touch', so every hot page pays the full image again. ## Protection 2: doublewrite area An alternative: keep a dedicated, contiguous region on disk (the doublewrite buffer). Flushing works in two stages: 1. Write the batch of pages sequentially into the doublewrite area and flush it. 2. Write each page to its real home location. If a crash tears a home-location write, recovery finds the page's checksum invalid and copies the intact copy from the doublewrite area. If the crash happens during stage 1, nothing is lost - the home pages are still their previous valid selves. The cost is that every page is written twice. It is less painful than it sounds, because the doublewrite writes are sequential and batched, but it is real and it is why the mechanism is sometimes disabled on storage that guarantees atomic page-sized writes. ## When protection can be turned off Both mechanisms are insurance against non-atomic page writes. If the storage stack genuinely provides atomic writes at the page size - some enterprise SSDs, some filesystems with copy-on-write semantics or explicit atomic-write support - the protection is redundant and can be disabled for a substantial reduction in write volume. The judgement required is real: the claim must hold for the *entire* stack, including any virtualization, RAID layer, and the filesystem, not just the drive's datasheet. Disabling it on an unverified stack converts a rare crash into silent data corruption, so the default answer in an interview is 'keep it on unless you can prove atomicity end to end'. ## What to say in an interview Define the tear (page > atomic write unit), explain why it defeats redo (the page is not a valid version and its header cannot be trusted), name both protection styles and the cost each pays, and note the tuning consequence that more frequent checkpoints increase full-page-image volume.