The Unwritten Contract of Solid State Drives

Abstract

We perform a detailed vertical analysis of application performance atop a range of modern file systems and SSD FTLs. We formalize the "unwritten contract" that clients of SSDs should follow to obtain high performance, and conduct our analysis to uncover application and file system designs that violate the contract. Our analysis, which utilizes a highly detailed SSD simulation underneath traces taken from real workloads and file systems, provides insight into how to better construct applications, file systems, and FTLs to realize robust and sustainable performance.

uFLIP-OC

“…We start by discussing the impact of media characteristics and then the impact of parallelism. We discuss lessons we can derive from these results about the SSD performance contract of He et al [5] in the next section.…”

“…The unwritten SSD contract and the five rules identified by Hen et al [5] were defined for SSDs equipped with embedded FTL. Let us revisit how these five rules apply to open-channel SSDs in light of the results of the uFLIP-OC benchmark applied on the DFC equipped with the OX controller.…”

“…Recently, He et al [5] discussed the "unwritten contract" of traditional SSDs, i.e., SSDs equipped with an embedded Flash Translation Layer, that provide the block device abstraction (initially defined for magnetic hard drives): a linear space of logical block addresses (LBAs) associated with read and write operations. According to He et al, systems implemented on top of SSDs should follow five rules: (i) request scale rule: submit large requests or many outstanding requests, (ii) locality rule: favour locality to minimise misses in the FTL mapping table, (iii) aligned sequentiality: write sequentially within a block, (iv) grouping by death time: group on the same blocks data that is updated or deleted together, and (v) uniform data lifetime: favour data structures where data are updated/deleted in batch.…”

BoLT

“…Since the compaction keeps rewriting the same key-value pairs from one file to another file multiple times, it results in high write amplification and suffers from storage wear issues. Besides, the compaction thread often blocks writers from inserting new records into an in-memory buffer space called MemTable until a background thread finishes compaction [20,25,30]. The so-called write stall problem is known to hurt the write throughput of LSM-tree significantly [8,12,21,[24][25][26][27][28]30].…”

“…However, none of these previous research has investigated the data barrier overhead of the compaction process. Although the default write size between barriers in LevelDB is moderately configured (about 2MB on average), the frequent fsync()/fdatasync() calls will cause disk bandwidth under-utilized, thus making the key-value stores to perform sub-optimally [20].…”