All SSDs include flash memory to store the data, a hardware controller and associated firmware that manages where and how the data is stored, and the host bus interface. To keep track of how the data is organized on the media, a mapping table is stored on the SSD. Some SSDs add RAM to increase the amount of mapping data immediately available and to cache data that has been written by the host system. Flash controllers with minimal RAM will read these mapping tables out of flash more frequently, reducing performance and increase the likelihood of read disturb.
RAM in an SSD can also enable the caching of writes, improving the appearance of its write performance. Depending upon the type of FTL used in the SSD (page- vs block-based) larger and more sophisticated mapping tables are needed.
Basic SSD Architecture
The architecture diagram below shows the basic elements of an SSD, although the specifics can vary greatly as you climb the price curve. On higher-end SSDs you will likely find a separate RAM buffer in addition to RAM in the controller. This element would likely not exist on a low-cost USB disk which only uses the RAM found in the controller.
Managing Flash Memory is Complex
Flash pages cannot be programmed until the page has been erased. While individual pages can be written, erases must be done on blocks, which contain many pages. Each time a page is written an entry is made into a mapping table to help the FTL “find” the data again when it’s needed. This means that any valid data included in the block to be erased must be moved to an already-erased block. Erasing flash blocks is an order of magnitude slower than reading or writing a page and flash memory is limited in the number of times it can be erased.
- [block-based: to change a single page, read the block into RAM, change a page, write the block back out to a new location on the flash]
- Some writes to flash memory are faster than others and the manner in which the flash is originally written can impact performance of subsequent writes.
- Complex data structures are required to map, remap and un-map a page of flash memory to a new Logical Block Address (LBA). These complex structures must be stored in the same flash page in which the user data is stored.
- When pages are re-mapped or un-mapped, then they need to be recycled (erased and marked as free) using garbage collection. There must always be extra flash free space to write garbage collected data.
- Blocks of flash may be bad when manufactured and a portion are expected to fail during the normal use of the flash.
- Reading flash memory may not return the exact data that was written to it, so Error Correction Codes (ECC) must be written with the data to correct any errors that are found during reading.
- If you read a single page of flash too much, then it may change the data in other pages around the heavily read page. The phenomena, called read disturb is especially problematic because the disturbance in the page that isn’t being read may go unnoticed for a while.
- If a power loss occurs while writing to MLC or TLC flash, then data previously successfully written to flash may be altered also.
- The current trend in flash memory is smaller lithography and higher density. All of the challenges in storing data in flash memory mentioned previously only increase with the smaller lithography and more bits per flash cell.