Understanding SSDs

The Characteristics of SSDs

Solid-state drives (SSDs) are a type of nonvolatile storage device that uses flash memory to store data. Unlike traditional hard drives, SSDs have no visibly moving parts, which makes them faster and much less likely to lose your data if you drop them. They're also more energy-efficient and produce less heat than traditional hard drives.

Performance

Let's compare the performance of SSDs to traditional hard drives, comparing at the top end of each technology:

Performance Metric	NVMe SSDs (PCIe 4.0)	Fastest HDDs (15,000 RPM)
Sequential Read	Up to ~7 GB/s	~275 MB/s
Sequential Write	Up to ~7 GB/s	~275 MB/s
Access Time	20-50 µs	5-10 ms

Physical Structure

The flash memory in an SSD is organized into blocks, which are further divided into pages. Each page is the smallest unit of data that can be read or written to the flash memory. When data is written to an SSD, it is written to an entire page at a time. Some typical sizes are:

• Page size: 4–8 KB
• Block size: 64–256 pages (0.25–2 MB)

Let's dive into looking at the behavior of SSDs with a simulation. In the simulator below, we have a small SSD, and for now, we're just simulating the bare hardware of the flash memory. We'll assume reading is straightforward and analogous to reading RAM. We'll focus on writing and erasing…

SSD Simulator

Explore!

The toggle under the visualization lets you switch modes between writing (also sometimes called “programming”) and erasing. The drop-downs let you change the size of the SSD, but for now leave it on the smallest size. As we learn more, we'll have different levels of sophistication, but for now you can only select “Physical Basics” from the drop-down for properties.

• When you hover the mouse over a page, you can see various details about it and its enclosing block.
• Click on some of the pages to write them.
  • Once a page is written, we can't write to it again until it has been erased.
• Switch to erase mode and try doing some erasing. The way erasing works may surprise you.
• Focus on one block and do multiple writes and erases to it.
  • To speed up the process, you can just hover the mouse over a cell and press “w” or “e” to write or erase it.

An Analogy

One analogy for the physical behavior of flash memory is that it's just like using an old-school pencil and paper. When you write with a pencil, it makes an impression on the paper so it's no longer pristine. Similarly, it's harder to erase a single letter in the middle of a word, so you have to erase the whole word and rewrite it. And too many erasures and rewrites (or a coarse eraser) will wear out the paper, making it harder to write on and eventually impossible. (It might even make a hole in the paper!)

A Simple Solution?

Let's try it out! Click the button below to enable and select this feature in the simulator.

Now, when you try to erase a single page,

1. The simulator will first copy all the other written pages from that block into RAM (note that data in the computer's RAM is not on the SSD and so is not shown in the simulator)
2. Then it erases the entire block
3. Finally, it writes back all the saved pages (except the one you wanted to erase)

Scroll back and try writing to several pages in a block, then erasing just one of them. Watch how the process unfolds…

Overprovisioning and Block Remapping

Let's add a new feature: spare blocks we can remap. Click the button below to enable and select this feature in the simulator. The idea of keeping some blocks spare is called overprovisioning. When a block wears out, we can just remap it to a spare block and keep going.

Click the button below to enable and select this feature in the simulator, where we've reserved the last two blocks as spares (reducing our user-visible space from eight to six blocks).

Experiment with writing and erasing pages, and see how the simulator handles block wear and remapping. Try to wear out a block and see what happens. Also notice that the tooltip now shows the user-visible block number and the physical block number (smaller, in parentheses after the user-visible number).

Block Remap on Erase for Simple Wear Leveling

Because we can already remap blocks, we have a mechanism that we can use to reduce wear. We can erase a block and then juggle the mapping around to point at a block with less wear instead of just reusing the erased block. This approach allows us to spread wear damage across all the blocks more evenly and make the SSD last longer. It also avoids the risk and overhead of copying all the data to RAM and back, since we only erase the source block when data has been successfully copied to a new block and the mapping has been updated.

Note that now it very quickly becomes the case that where something is physically located on the SSD and where it is located logically is quite different. So it makes sense to give the part of the system that performs this remapping a name: the Flash Translation Layer (FTL). It maps user-centric LBAs to the physical blocks and pages on the SSD.

When you click the button below to enable support for the Flash Translation Layer, it will enable two new features in the simulator:

• Auto erase: Now, when you try to write a block, if it has already been written to, the SSD will automatically erase it first.
• LBA entry: Rather than laboriously clicking on each page to write, you can now enter a range of LBAs to write to. For example, entering 5-10, 3, 15 will write to LBAs 5, 6, 7, 8, 9, 10, 3, and 15. (The simulator will even show you a progress bar as it works through your list of LBAs.)
  • Slightly confusingly, the term “LBA” means “logical block address” in the same sense we used it with spinning disks, where it referred to the logical sector number. Here, it's really a logical page number. We'll stick with the common (mis)usage, but we'll always just say “LBA” rather than expanding it to its (confusing) full name.

Click the button below and scroll up and play with the simulator. But before you try a long sequence of LBA requests, first try writing and erasing a few pages to get a feel for what is going on. Remember, the mouse tooltips show you the logical and physical block numbers.

In the simulator we can see which blocks are the most worn and target them, but a real SSD doesn't supply that information. But it turns out that remapping blocks according to a predictable pattern is almost as risky, because an adversary could predict which blocks will be most worn out and target them for writes (or, in a less hostile world, we could just have an access pattern that coincidentally aligns with the remapping pattern). So in future, we'll adopt a random remapping strategy to avoid this issue—you'll still be able to see which blocks are most worn in teh simulator, but only the drive itself would know in the real world.

Now, let's return to the idea of saying, “I don't care about this page anymore”….

Trimming

Telling the SSD that you no longer care about a page is called trimming. When you trim a page, the SSD knows it contains garbage data and can skip copying it when it remaps the block, which saves a lot of work and wear on the SSD.

When you click the button below to enable both trimming and random block remapping, you'll see the SSD start to behave more like a real SSD. The simulator will now

• Use trim: When it has a range of LBAs (pages) to write, it will first trim all the LBAs that are going to be written, so the SSD knows they're garbage and doesn't have to copy them if it needs to remap the block.
• Garbage pages: When a page is marked as garbage, it will be shown in a dark blue color.
• Random remapping: Instead of remapping blocks in a predictable pattern, the simulator will now remap them randomly, making it much harder for an adversary to predict the new location of the worn blocks.
• Runs faster: As we have to do more work to wear out the disk, we've sped up the simulator a bit.

Experiment with the simulator and see how trimming and random remapping change the behavior of the SSD. Try writing to a range of pages and see how the SSD behaves.

Page-Level Remapping

In our page-level remapping scheme, when we want to erase a page to write new data, we'll mark the existing physical page as garbage and adjust the page mapping to move one of the other, not-yet-used, pages in to take its place.

Click the button below to enable page-level remapping in the simulator. We've also sped it up just a little more when running LBA request sequences. It's probably a good idea to first click on blocks with the mouse to write and erase a few pages to get a feel for what is going on as manual changes run at the normal speed. Remember that you can mouse over the blocks to see the logical and physical block numbers, and now you can see similar information for pages as well.

Hybrid Remapping

Real-world SSDs use a variety of schemes in their flash translation layers to balance wear leveling, performance, and complexity. Many of these schemes are proprietary and they continue to be a matter of research. Some do use completely arbitrary page remapping, but that approach is more complex and can be slower and more demanding for space to store the mapping. We'll adopt a simple hybrid scheme.

The approach we'll use will only affect requests made in the LBA entry mode, because we'll do the remapping at the LBA-to-block/page level.

LBA Permutation

We'll pass each LBA address through a simple permutation function that will map it to a new LBA address. This remapping will spread the wear across the blocks and pages. The permutation is random, so it will be impossible to know where any given LBA will end up.

Click the button below to enable the hybrid-remapping scheme in the simulator. You can't just click on a cell to write to it now (that would be cheating!)—you have to use the LBA entry mode. Try writing to a range of pages and see how the SSD behaves.

We can mitigate the completely-full block issue somewhat by having some number of spare pages per block, which is a page-level version of the overprovisioning we had at the block level. We'll add this feature to the simulator now.

But perhaps the moral is, don't fill your SSD to the brim!

Trade-offs in SSD Design

Our journey through increasingly sophisticated SSD management has revealed several key trade-offs:

Space vs. Reliability

We've seen how allocating space for overprovisioning can improve reliability, whether we do it at the block or page level. But overprovisioning comes at the cost of reduced user-visible capacity.

Enterprise SSDs often reserve 20-30% of their capacity for overprovisioning, as well as error-correction codes and other reliability features. Consumer SSDs typically have less overprovisioning, but still enough to ensure good reliability, whereas a USB stick might have very little because it's designed for occasional use and to meet a low price point.

The extent to which a single page write causes more than a single page's worth of wear is known as write amplification. The more overprovisioning we have, the less write amplification we'll see.

For SD cards, cheap SD cards with low write endurance probably use QLC flash, while flash for high-endurance cards is likely to be MLC or TLC. Because the number of bits per flash cell drops, so too does the transfer speed as less data is stored in each cell.

FTL Design Complexity

In this lesson, we've seen increasingly sophisticated FTL designs to manage wear leveling, remapping, and garbage management. More complex FTLs can provide better performance and endurance, but they also require more resources and can be harder to design and test.

To meet price constraints, something like a USB stick might use a very simple FTL, whereas a high-end enterprise SSD might have a very complex FTL to ensure consistent performance and reliability under heavy workloads. Consumer SSDs fall somewhere in between.

Advanced features include

• DRAM caching of mapping tables
• Redundant storage of mapping tables on the drive itself
• Multiple block types
• Age tracking so that old data that is unlikely to be rewritten is grouped together in full blocks
• Migrating old data on lightly worn blocks to blocks nearing the end of their useful lifespan to obtain nearly fresh blocks for new data

Heavy users of large numbers of SSDs, such as large cloud providers, may find it to be cost effective to write their own custom FTLs optimized for their specific workloads.

Real-World Endurance

While our simulator showed blocks wearing out after just eight erases to make it easier to explore these concepts, real SSDs are much more durable.

• Modern SSDs can handle thousands to hundreds of thousands of write cycles per block
• Have more sophisticated wear leveling than our simple schemes
• Have much more space for overprovisioning
• Even consumer QLC drives (with ~1000 cycles per block) can last for years of normal use

Operating-System Support

Modern operating systems support SSDs in several ways:

• Use trim mark when data becomes garbage: Trim support allows the OS to tell the SSD that a page is no longer needed, improving performance and wear leveling
• Use native command queuing: NCQ allows the OS to optimize the order of read and write commands to the SSD—the more the flash memory knows about what's coming, the better it can optimize its wear leveling
• Respect alignment: Ensuring that file blocks are aligned with the SSD's page size can improve performance and endurance. For some SSDs with simple FTLs, aligning with the block size can be important, too.
• Avoid update-in-place: Where possible, it's usually better to add data to the end of a file rather than overwriting it in the middle. This approach can reduce write amplification and improve performance, especially for simple FTLs.
• Avoid swapping to SSD: Swapping memory pages to SSD can cause a lot of writes, so it's best to avoid it if possible as every write comes with a cost in wear. Apple's iOS, for example, doesn't use swap on its SSDs.

Although following these best practices can help improve SSD performance and endurance, modern SSDs are quite resilient and can handle a lot of abuse.

(When logged in, completion status appears here.)

Previous Page Next Page