How SSDs Handle Writes
SSDs pretend to be disks, but the flash memory inside them plays by completely different rules. Understanding those rules explains a lot of otherwise mysterious SSD behaviour, why they slow down when full, why they have a write endurance rating, and what TRIM is actually for.
The Asymmetry at the Bottom
NAND flash has a weird constraint set:
- You read and write in units of a page (typically 4–16 KB).
- But you can only erase in units of a block, usually 128 to 256 pages at once.
- And here’s the kicker: a page cannot be overwritten. Once written, it must be erased before it can be written again, and erasing means erasing its entire block.
So “update 4 KB in place”, the most basic thing a filesystem wants to do, is physically impossible on flash.
The FTL: A Lie That Works
The SSD controller solves this with the FTL (Flash Translation Layer). It maintains a mapping from the logical block addresses the OS sees to physical pages in flash, and it never updates in place. Instead:
- The new version of the data is written to some fresh, already-erased page.
- The mapping is updated to point there.
- The old page is just marked stale and left where it is.
If this sounds familiar, it should, it’s the same idea as a log-structured storage engine, or virtual memory’s separation of addresses from locations. The OS thinks it’s overwriting sector 12345; in reality the data wanders all over the flash and only the mapping table knows where anything lives.
Garbage Collection (Yes, SSDs Have One Too)
Stale pages pile up, and the only way to reclaim them is to erase whole blocks. So the controller runs a background garbage collector: pick a block that’s mostly stale, copy its still-valid pages to a fresh block, then erase the whole thing.
Those internal copies mean the SSD writes more data than you asked it to, this ratio is called write amplification. It’s also why SSD performance degrades as the drive fills up: fewer free blocks means the GC has to run more often and copy more valid data around per reclaimed block. Same fundamental trade-off as a memory GC with a nearly-full heap, one layer down the stack.
This is also why drives keep over-provisioned spare capacity, a hidden reserve of blocks so the GC always has somewhere to breathe.
Where TRIM Fits
When you delete a file, the filesystem just updates its own metadata. The SSD has no idea those pages are now garbage, as far as the FTL knows, they’re valid data it must dutifully copy forward during GC, forever.
The TRIM command fixes exactly this: the OS tells the drive “these logical addresses are dead to me”, and the FTL can mark the pages stale and skip them in future GC cycles. Less copying, less write amplification, longer drive life. Modern OSes send TRIM automatically on delete, so this mostly just works these days.
Why Endurance Is a Thing
Each flash cell only survives a limited number of program/erase cycles (a few thousand for typical consumer TLC flash). The controller does wear leveling, spreading writes across all blocks so no block dies early. That’s the origin of the TBW (terabytes written) rating on drive spec sheets: it’s the wear budget, with write amplification eating into it invisibly.
What strikes me about all of this is how much software is in the loop. An SSD isn’t a dumb storage medium, it’s a small computer running a log-structured storage engine with a garbage collector, translating between the interface disks have had since the 80s and physics that work nothing like it.