No moving parts changes everything
For three guides we have lived inside a hard disk: a stack of platters spinning thousands of times a minute, an arm darting in and out, and a read that costs three separate waits — seek to move the arm, rotation to wait for the right sector to come around, then transfer. A solid-state drive, an SSD, throws all of that machinery in the bin. There is no platter, no arm, no spinning. Data lives in flash memory, a grid of microscopic cells that each trap a few electrons to remember a 1 or a 0, with no moving part anywhere in the device.
The immediate payoff is staggering. With no arm to move and no platter to wait for, the two big costs from guide 2 — seek and rotation — simply vanish. Where a hard disk needs several milliseconds to position itself before a single random read, an SSD answers in tens of microseconds: roughly a hundred times faster, and the gap is even wider for the random scattered reads that punish a disk hardest. Better still, an SSD has no notion of "near" or "far": every location is equally quick to reach, because there is no physical distance to travel. That last property is the quiet bomb under everything we learned about disk scheduling, and we will come back to it.
The catch: you can't just overwrite flash
Here is the strange rule at the heart of flash, the one everything else is built to work around. Flash cells are organized into two different-sized units. The unit you can read or write is a page — confusingly, the same word as a memory page from the paging guides, but unrelated; here it just means a small chunk, often around 4 KB to 16 KB. The unit you can erase is a much larger erase block, a bundle of many pages, often a few hundred KB to a few MB. And the rule is brutal: you can write a fresh page, but you can never overwrite a page that already holds data. To reuse it, you must first erase — and erase only works on the whole big block at once, wiping every page in it.
Picture a page of a notebook written in permanent ink. You cannot edit a single line — to change anything on the page you would have to tear out and reprint the entire chapter the page belongs to. So if a program wants to change just a few bytes in the middle of a file, the drive cannot quietly overwrite them in place the way a hard disk would. Instead it writes the changed data to a brand-new, already-erased page somewhere else, and marks the old page as stale garbage to be cleaned up later. This little dance — write elsewhere, retire the old copy — is forced on every single modification, and it is the source of nearly every quirk that makes SSDs interesting.
There is a second, harsher fact hiding here: flash cells wear out. Each erase damages the cell a tiny bit, and after some number of erase cycles — anywhere from a few hundred to a few hundred thousand, depending on the flash type — a cell can no longer reliably hold its electrons and dies. A hard disk platter does not wear from being read or written; flash genuinely does. So the drive must not only juggle the erase-before-write rule, it must also spread the damage so no single block is erased to death while others sit idle. Both jobs land on one piece of cleverness we meet next.
The flash translation layer: a tidy disk faked on messy chips
How does an SSD honor that simple promise from guide 1 — "give me numbered block 5,000 and I'll read or write it" — when underneath it can never overwrite a page in place? It runs a small, secret operating system of its own. The flash translation layer, or FTL, is firmware inside the drive that keeps a map: for each logical block number the OS asks about, it records which physical flash page currently holds that data. When you "overwrite" block 5,000, the FTL writes the new data to a fresh page, then just updates the map to point block 5,000 at the new page and marks the old one stale. The OS never sees any of this — it thinks it overwrote a block, exactly as it would on a disk.
OS asks: write logical block 5000 (new contents)
logical block -> physical flash page
before: 5000 -> page A (now stale)
after: 5000 -> page G (fresh, just written)
page A is left as GARBAGE; reclaimed later, in bulk,
by erasing the whole block it sits in.That indirection layer is exactly where the drive solves its two hard problems. Because the FTL gets to choose which physical page each write lands on, it can practice wear leveling — see wear leveling — deliberately steering writes toward the least-erased blocks so that wear spreads evenly across the whole chip instead of hammering one spot. Without it, the blocks holding a busy log file or file-system metadata would erase themselves to death in months while gigabytes of cold blocks sat fresh and unused. With it, the whole drive ages together, gracefully, and lasts far longer than any single cell would on its own.
Garbage collection, write amplification, and TRIM
All those stale pages do not clean themselves. Eventually the drive runs low on fresh, erased pages and must reclaim space — a process called garbage collection. But remember the erase rule: you can only erase a whole block, and a block almost always holds a mix of stale pages and pages still in use. So before erasing, the drive must first copy every still-live page out of that block into a fresh block, then erase the old one. Each user write thus quietly triggers extra internal copying, and that gap between bytes the user asked to write and bytes the flash actually had to write is called write amplification. It is the hidden tax of the erase-before-write rule.
- The drive is low on free pages, so garbage collection picks a victim erase block — say one with 60 live pages and 4 stale ones.
- It copies all 60 live pages out into a fresh block somewhere else, and updates the FTL map for each one to point at its new home.
- Now the victim block holds only dead data, so the drive erases the whole block in one shot, returning 64 freshly empty pages to the pool.
- Net result: to free up 4 stale pages, the drive physically wrote 60 extra pages it was never asked to write. That ratio is the write amplification.
Now a subtle gap appears between the OS and the drive. When you delete a file, the file system just marks those logical blocks free in its own bookkeeping — it does not touch the data, exactly as you learned for disks. But the FTL cannot read the file system's mind: it still believes those stale pages hold precious live data, so it dutifully copies them around during garbage collection forever. The drive is slaving away to preserve data nobody wants. The fix is the TRIM command — see TRIM — a message the OS sends to tell the drive "these logical blocks are now free; their contents are garbage, you may stop preserving them." With TRIM, the FTL can drop those pages instead of copying them, which cuts write amplification and keeps the drive fast as it fills.
The elevator stops here
Now we can detonate that quiet bomb from the first section. The previous guide spent its whole length on disk scheduling: reordering pending requests so the disk arm sweeps the platter efficiently, like an elevator serving floors in one smooth pass instead of bouncing up and down. SSTF always jumps to the nearest request; SCAN (and LOOK) sweep in one direction then back. Every one of those algorithms exists to minimize seek time — to reduce how far the arm physically travels. On an SSD there is no arm and no seek time, so there is no "distance" to minimize. The entire premise the elevator algorithm was built on simply does not exist.
So on an SSD the clever sweep barely helps. Reordering requests to be "closer together" wins essentially nothing, because every page is equally close. Real operating systems noticed: Linux, for instance, offers a near-trivial scheduler (and an option to do almost no reordering at all) for flash, instead of the elaborate elevator it still keeps around for spinning disks. The point of disk scheduling has shifted from minimizing arm travel to other goals entirely — keeping the SSD's many internal channels busy in parallel, batching small writes, and being fair between processes — which is a different and gentler problem.
What an SSD does not fix — and what's next
It is tempting to think the SSD solved storage. It did not. Be honest about its limits. An SSD is still vastly slower than main memory and the caches above it — the storage hierarchy from guide 1 is squashed, not abolished, and the gap between RAM and flash is still wide enough that the OS keeps caching disk data in memory exactly as before. Flash cells still wear out, so an SSD has a finite write budget that a hard disk does not. And crucially, an SSD is still one device: when its controller fails or its chips die, every byte on it can vanish in an instant, the same as a disk losing a head crash.
Notice the thread that ran through this whole guide: indirection saved us. The FTL is, at heart, a map from logical to physical — the very same idea as a page table mapping virtual addresses to physical frames, or logical block addressing mapping block numbers to disk geometry. Each time the system needed a hard physical reality to wear a clean, stable face, it inserted a layer of translation. That single move — a map between names and locations — is one of the most reused ideas in all of computing, and you have now seen it solve three completely different problems.
But the unsolved problem — one device, one point of failure — is the biggest one left, and it is where this rung ends. No matter how fast or clever a single drive is, if losing it loses everything, you have not really solved storage; you have just made the cliff edge faster to reach. The final guide tackles this head-on with RAID: combining several drives so that they are faster together (striping), or survive one another's death (mirroring and parity), or both — and confronts the uncomfortable truth that more drives means more things that can break, and that rebuilding after a failure is itself a moment of real danger.