Solid-state drive architecture

SLC and MLC memory is a complex technology that should be properly managed to ensure that it provides all its potential benefits. Solid-state drives are the most popular

implementation format of this technology in the enterprise storage space. Figure 1-9 on page 19 demonstrates the common architecture of the SSD.

Note: There are MLC flash chips that can store three or four bits per cell. For the purposes

Figure 1-9 Architecture of the solid-state drive

Following are basic components of the SSD:

򐂰 Flash memory

򐂰 Disk controller

򐂰 Interface controller

Depending on the manufacturer, there might be other components included in the SSD, such as additional flash memory controllers, error correction code (ECC) controllers, and additional blocks in the disk controller.

Flash memory

Flash memory is the basic component of the SSD that provides the data storage. Depending on the disk purpose, the memory can be SLC or MLC. The amount of raw memory capacity in the SSD is usually several percent more than the usable capacity. This additional memory capacity is used for data placement, one of the key techniques used to address wear-leveling and increase the lifetime of the SSD. Flash memory components also include all necessary communication and ECC controllers.

Interface controller

The interface controller is responsible for presenting the SSD as a SATA, SAS, or FC drive in the operating system or external disk system. It also includes all necessary communications, connectors, and controllers.

Disk controller

The disk controller is a key component of the SSD architecture, and commonly the technology that differentiates the SSD drives of various manufactures. In general, the disk controller is the System-on-Chip (or several chips) representing the processor, firmware, random access memory (RAM), flash translation layer (FTL), wear-leveling algorithms, ECC controllers, and possibly, other components for encryption, data deduplication, additional aging prevention, and so on. The disk controller provides the following functionality:

򐂰 Flash translation layer function

򐂰 Garbage collection function

򐂰 Wear-leveling function

Flash translation layer

The flash translation layer emulates a standard block device by exposing only read/write operations to the upper software layers. It performs the virtual-to-physical address

translations and hides the erase-before-write characteristics of flash memory. The FTL also emulates the over-write operation with out-of-place updates. In out-of-place updates, the physical location of data is changed on every write request, and the FTL maintains a mapping table between the logical sector and physical location. The address mapping table is usually stored in a small piece of RAM. According to the size of the mapping unit used, FTL schemes are classified as block mapping, page mapping, and hybrid mapping5. The flash translation layer also provides garbage collection and wear-leveling capabilities that are vital to the performance and reliability of flash SSD.

Garbage collection

Garbage collection (GC) is a process that erases dirty blocks and recycles their obsolete pages. If a block that is selected for erasure has some valid pages, those pages are migrated to other blocks before erasing the block. Because garbage collection involves time-consuming erase operations and numerous internal reads and writes, an ongoing GC process can stall incoming user requests until it completes. As a consequence of the queuing delay, the performance of flash SSD can be significantly degraded by 20%6. Various GC mechanisms have been proposed to minimize the garbage collection overhead. In particular, much effort has been focused on reducing the total amount of copied data from the erased blocks, because moving valid data from erased blocks to new blocks represents a large portion of the total execution time of a garbage collection process. The most common way to achieve this goal is to separate data based on update frequency, so that the number of obsolete blocks (that is, blocks that have no valid data) and almost-obsolete blocks (that is, blocks that have very little valid data) can be increased. Recycling obsolete or almost-obsolete blocks can substantially reduce overhead.7

Wear-leveling

The purpose of wear-leveling algorithms is to evenly distribute block erasures over the flash memory, and thus enhance its endurance. Wear-leveling algorithms can be classified into dynamic wear-leveling and static wear-leveling.

Dynamic wear-leveling

The performance of dynamic wear-leveling depends on hot and cold data identification. Cold data always stays in the same blocks, regardless of whether updates to hot data wear out 5 _{Covering these techniques is out of the scope of this book. For more information, refer to the following paper:}

Hot/Cold Clustering for Page Mapping in NAND Flash Memory, Ilhoon Shin, IEEE Transactions on Consumer Electronics, Vol. 57, No. 4, November 2011.

6 _{Estimated value, might vary.}

7 _{For more information about garbage collection techniques, refer to this paper: Making Garbage Collection Wear} Conscious for Flash SSD, Jonathan Tjioe, Andrés Blanco, Tao Xie, Yiming Ouyang; 2012 IEEE 7th International Conference on Networking, Architecture, and Storage.

other blocks. In a conditional threshold wear-leveling algorithm, when a block is erased, the cold data in the block with the minimum erase count is moved to the newly erased block, effectively swapping hot data and cold data.

Static wear-leveling

In static wear-leveling, when the difference between the maximum block erase count and minimum block erase count exceeds a specified threshold, static data is moved to the hot block to balance the erase count in each block. Accordingly, a block erasure table (BET) is created to identify which blocks have been erased during a given time period.

The wear-leveling threshold for various system environments can be very different. Using inadequately tuned parameters can cause unexpectedly high wear-leveling overhead and poor wear-leveling performance. The implementation complexity of the wear-leveling algorithm determines the applicability of the algorithm. Existing wear-leveling algorithms require prior knowledge of the system environment for threshold tuning, and thus increase their design complexity.8