Pragmática

Since Flash storage is prone to wear and has a limited lifetime, it is crucial to provide appropriate I/O patterns in order to improve the endurance. Growing Flash capacities for SSDs entail the trend to larger erase units, since larger sizes allow the use of smaller mapping tables on the SSD’s controller. Since wear on the device is measured using the average amount of erases, avoidance of small updates, such as timestamp related meta-information becomes more important. The

Figure 2.5: Latency outliers on random write load on a single SSD with factory clean state. Du- ration 60 seconds and 335k write requests. The abscissa is showing the number (in order) of each write request. The ordinate is showing the latency of each request.

SIAS algorithm significantly reduces the write amount and the required space on the device. In-place updates are avoided, new pages are written (appended) in monotonically increasing order.

Masked Behavior

The FTL emulates an HDD compatible block device interface and hides internal background processes that manage the Flash memory. A black-box abstraction is created that hides internals and specifics of the Flash memory. The basic background processes are represented by a logic block mapping, the garbage collection and wear leveling algorithms. These background pro- cesses run asynchronously and are triggered on certain conditions based on the device specific state.

This organization leads to a crucial property: unpredictable performance in terms of latency and throughput. The black-box abstraction leads to an interference between the execution of foreground I/O requests (issued by the DBMS) and the background processes on the device.

When the (volatile) cache is filled during normal database execution, the performance drops since write operations have to be carried out. In modern SSDs there exists a so called spare area which is additional space available only for the internal device. Error correcting codes are also stored within that area. If the spare area is saturated or a block has been remapped again, expensive erase-modify-write operations have to be executed. Such executions produce outliers in latency and throughput, which is unpredictable to the software behind the device interface. Although the DBMS issues a sequential scan over its logical block addresses the SSD may have to find remapped physical blocks at different locations.

Unpredictable Performance.

The address mapping (Figure 2.3) and background processes that manage the Flash chips (garbage collection, wear leveling, etc.) and provide the legacy interface create a black box abstraction which creates state dependencies and prevents stable performance characteristics. Sporadic non-deterministic and workload dependent outliers occur, as depicted in Figure 2.5.

A single SSD is instrumented with 60 seconds of random write requests, with a total of 335k requests. We measured each write request’s completion time. The difference between the aver- age and maximum request latency is significant. The main reason for this behavior is Garbage Collection. The FTL runs a garbage collection (GC) process that is executed asynchronously. Used blocks are collected and co-located such that erase units can be erased to reclaim space. In most SSDs the GC process is triggered in the background when the device is idle or when a threshold (used up space) is reached.

State Dependency

Figure 2.6 shows the state dependency of the Intel X25-E SLC SSD. We conducted I/O bench- marks where each I/O trace is comprised of mixed random read and random write requests and is created with an individual seed. Each trace was run consecutively for eight times. After each individual test-run, the system was powered down and restarted in order to remove caching effects. With each consecutive run, using the same seed, the SSD performed better. After switching to a different seed, practically creating a different trace, the performance broke down to the point of each initial benchmark series. This emphasizes the existence of state dependency on Flash devices that are caused by internal processes and the occurrence of remapping on the device. Therefore, it is difficult to guarantee certain performance figures as long as the I/O pattern is not optimized.

1 2 3 4 5 6 7 8 Seed 20 31392 51807 59174 70305 74739 81847 84035 91056 Seed 42 33893 55930 57804 77522 73725 88827 87352 99010 Seed 173 35036 55064 65633 74620 81157 88424 93077 97537 Seed 65 34314 53855 63615 73538 79770 87545 92272 97154 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 100000 110000 IOPS

SSD state dependency

Figure 2.6: SSD state dependency. Each seed forms a series of 8 test-runs that are consecutively executed. After each run the system was powered off. When the same trace is exe- cuted, the SSD performs better - even after a power loss. Thus making it difficult to guarantee reliable performance figures.

Trim

If the host system is not aware of the underlying SSD storage it does not inform the SSD when a block is deleted, since usually only an entry within the filesystem is updated. Traditional HDD storage devices do not need the trim command since they are capable to overwrite blocks. Since the block has to be explicitly erased on the SSD, the SSD is not able to garbage collect that block if only the filesystem is updated. Therefore, the Trim command was introduced that informs the SSD about the deletion of blocks. This is beneficial for the efficiency of the SSDs background processes such as garbage collection and wear leveling. Trim is implemented in modern operating systems such as Windows 7, Linux (kernel 2.6.33) and Max OS X (10.6.8). Flash Write Amplification

The general term of write amplification is the difference of new data that has to be written and the actual amount of data that has to be written. For example overhead that is generated by meta-data and (hardware/software) interfaces.

Flash write amplification (F-WA) is the result of data written by the SSD’s controller divided by write operations issued by the host The host accesses the SSD through a block-device interface. If the host is unaware of the underlying Flash, it may issue overwrites that on the SSD trigger a costly erase-cycle - this has to be avoided in order maintain sustained performance, reliability and longevity. Operations such as the remapping of Flash-blocks or migrating of valid Flash- pages within a Flash-block, creates the F-WA. The numerical value of F-WA is calculated dividing the amount of data written by the SSD’s controller by the amount of data that is written by the host. In the ideal case the number is smaller or equal to one. If it is smaller than one the data written by the host is compressed by the SSD’s controller.