Erase Blocks, Pages, and the Asymmetry That Shapes Flash Storage

A hard disk presents an array of sectors, each rewritable in place an unlimited number of times. Every layer above the device is built on that assumption: the filesystem allocates a block and overwrites it, the journal writes a commit record over the previous one, the page cache writeback path rewrites a dirty page at the same address. NAND flash does not satisfy the assumption. A cell that has been programmed must be erased before it can be programmed again, erasure works on a unit far larger than the write unit, and both operations consume the cell a little. Flash translation, garbage collection, over-provisioning and discard all exist to make code written for in-place rewrite behave correctly on a medium that cannot do it.

Two granularities that do not match

NAND is organized as dies, each divided into planes, each holding erase blocks, each holding pages. The page is the unit of read and program. The erase block, sometimes called the physical block, is the unit of erase. A representative geometry: 4 KiB pages, 256 pages per erase block, so a 1 MiB erase block, with a few hundred thousand blocks on a drive of a few hundred gigabytes. Page sizes from 2 KiB to 16 KiB and block sizes from 128 to 512 pages all appear across parts. The exact figures are part-specific; the ordering, page much smaller than block, is not.

A program operation places charge on the cells of one page, moving each cell’s threshold voltage into one of several bands. With one bit per cell there are two bands, with two bits four, with three bits eight, with four bits sixteen; the cell technologies are named SLC, MLC, TLC and QLC in that order. An erase operation removes charge from an entire block at once, returning all of its pages to the erased state. No command erases a single page. That single fact is the origin of nearly every complication in this cluster.

The block layer’s view is different again. It sees logical block addresses, conventionally numbered in 512-byte or 4096-byte units, and it issues reads and writes to ranges of them. The controller is free to satisfy a write to LBA 1000 by programming any free page anywhere on any die, and it is free to satisfy a read of LBA 1000 from a different physical page each time. Only the contents are contractual; the location is not.

Why permanent mapping fails

Suppose a controller mapped each logical block to a fixed physical page. Rewriting one 4 KiB block would require reading the other 255 pages of its erase block into a buffer, erasing the block, and writing all 256 pages back. A single logical 4 KiB write becomes 1 MiB of program traffic, a write amplification of 256. On a device whose endurance is measured in thousands of program/erase cycles per block, that is not a performance problem but a lifetime problem: the block is consumed by a write that touched one page of it.

The alternative is to remap. The logical block is written to a free page, and the controller records the new location in a table; the old page is marked invalid. One page is programmed, one table entry changes, and the cost of reclaiming the invalid page is deferred. This is the founding decision of the flash translation layer, and the organization of that table is the subject of how logical addresses are mapped to physical pages. Deferring the cost does not eliminate it: invalid pages accumulate, and eventually a block full of them must be reclaimed by copying its few valid pages elsewhere and erasing it.

Programming order inside a block

Pages within an erase block are not independently writable in any order. Programming raises the voltage on a wordline and the neighbouring wordlines see a fraction of it, shifting the thresholds of cells that were programmed earlier. Controllers therefore require pages to be programmed sequentially from the first page of the block, and multi-level cells add a constraint within a wordline: the lower page and upper page of the same wordline are programmed in a defined order, because the upper-page program step must know the lower page’s state. A controller that writes pages out of order produces data that reads back with errors, and most devices will reject the attempt outright.

Some devices allow a page to be programmed in a few partial steps, typically through separate program commands that each fill part of the page buffer, but the page is still effectively single-shot: once the final program step completes, the page cannot be rewritten until its block is erased. The block layer cannot rely on partial-page writes being supported, and in practice it never issues anything smaller than a logical block.

The per-page state machine is small enough to state completely.

enum page_state {
    PAGE_FREE,        /* erased, never programmed since the last erase */
    PAGE_PROGRAMMED,  /* holds data; valid or invalid is an FTL notion, not a media one */
};

struct block_geometry {
    uint32_t page_size;       /* bytes of user data per page */
    uint32_t pages_per_block;
    uint32_t spare_bytes;     /* out-of-band area per page */
};

/* A block can only be erased after every one of its pages has been
 * programmed at least once. Whether those pages are still valid is the
 * controller's bookkeeping, not a property of the media. */
static bool block_fully_programmed(const struct block_geometry *g,
                                   const enum page_state *pages)
{
    for (uint32_t i = 0; i < g->pages_per_block; i++)
        if (pages[i] == PAGE_FREE)     /* still writable: no reason to erase */
            return false;
    return true;                       /* caller also needs a low valid count */
}

The state that matters to the controller is richer than this: each programmed page is either valid, meaning the mapping table still points at it, or invalid, meaning a later write superseded it. A block is worth reclaiming when the number of valid pages in it is low, not when it is empty. The choice of which block to reclaim and what that costs is garbage collection and the write amplification it creates.

The spare area and what lives beside the data

Every page carries bytes beyond the user data, in an out-of-band area. On a 4 KiB page the spare area is on the order of a hundred to a few hundred bytes depending on the part. It holds the error-correcting parity the controller computes at program time, and it usually holds per-page metadata: a sequence number that orders writes, the logical address the page was written for, and block health counters. The logical address stored beside the data is what lets a controller rebuild its mapping table after an unclean power loss, by scanning blocks and reading their spare areas rather than trusting a table that was only partially written.

Error correction strength scales with the medium’s difficulty. Early devices used BCH codes with a few dozen correctable bits per kilobyte; contemporary devices use LDPC codes whose soft-decision decoding handles a much higher raw bit error rate. The device’s internal ECC protects the die and the channel to the controller. It does not protect the path from the filesystem to the controller, nor the controller’s own DRAM, which is why filesystem-level checksums and T10 protection information remain necessary above a device that already corrects errors internally.

Read disturb, retention, and writes caused by reads

Reading is not free of side effects. To read one page, the controller applies a pass-through voltage to every other wordline in the block, and each read shifts the thresholds of the unread cells by a small amount. After enough reads of the same block, in the range of tens of thousands to millions depending on the part and the cell technology, pages that were never rewritten acquire uncorrectable errors. Controllers keep a per-block read counter and relocate a block whose count crosses a threshold, so a workload that only reads still produces writes.

Retention works in the opposite direction over time. Charge leaks from the floating gate or the charge-trap layer, and the leakage rate rises steeply with temperature. A drive that was written and then powered off for a long period at elevated temperature can return errors on pages that were verified correct when written. Both effects mean a read error is not evidence of a failed write; it can be the medium aging under a workload that never wrote to that page.

What the layers above may assume

Four assumptions survive contact with flash, and everything else must be negotiated through the block layer’s interface.

A logical address has contents, not a location. Nothing above the device may infer physical adjacency from logical adjacency, which is why filesystem allocation policies that assume locality across a range of blocks have no guaranteed effect on a flash device.

Writes to the same logical address are ordered with respect to each other. Writes to different addresses are not ordered unless the request carries an ordering flag or is separated by a cache flush; that contract is examined in flush, FUA, and write cache ordering.

The logical block size is an interface convention. A device with 4 KiB pages and 512-byte logical sectors will accept a 512-byte write and perform a read-modify-write internally to fill the page; the cost of that is taken up in sector size emulation and alignment.

The device may relocate, rewrite, or discard data at any time, as long as a subsequent read of the address returns the last written value. Every mechanism in this cluster is an exercise of that freedom.

What does not survive is the expectation of unlimited rewrite. Each erase consumes part of the cell’s endurance budget, quoted as a number of program/erase cycles that decreases as bits per cell increase: SLC parts are rated in the hundred-thousand range, and each step toward more bits per cell cuts the rating substantially, with QLC parts rated in the low hundreds to low thousands. The budget is per block and the workload is not spread evenly, so a controller that maps hot logical addresses to a fixed set of blocks burns them out while the rest of the device is barely used. Spreading the cycles is wear leveling, and it is the second thing an FTL must do after it learns to remap at all.