Source-linked AI summary
uFLIP: Understanding Flash IO Patterns
Luc Bouganim, Björn Jónsson, Philippe Bonnet
TL;DR
Flash devices are complex black boxes, making it unclear which IO patterns storage systems should favor or avoid. The paper introduces uFLIP and a flash-specific methodology, applies them to eleven devices, and derives design guidance from the observed performance patterns.
Problem
Flash devices are complex, undocumented black boxes, so the IO patterns relevant to flash-based algorithms and architectures are not yet comprehensively understood.
Method
The paper defines uFLIP, nine IO-pattern micro-benchmarks, and a benchmarking methodology that models start-up and running phases while controlling experiment state and length.
Results
High-end SSDs substantially outperform other devices and handle unusual patterns better; random writes are typically near sequential-write cost over 4–16MB but expensive over larger areas.
Takeaways & Limitations
The results support using 32KB blocks as a current trade-off and limiting random writes to focused areas when designing flash-based systems.
Takeaways & Limitations
Choosing an appropriate IOCount remains manual: overestimation wastes time, while underestimation reduces precision and can produce incorrect results.
Abstract
from arXiv · showhide
Does the advent of flash devices constitute a radical change for secondary storage? How should database systems adapt to this new form of secondary storage? Before we can answer these questions, we need to fully understand the performance characteristics of flash devices. More specifically, we want to establish what kind of IOs should be favored (or avoided) when designing algorithms and architectures for flash-based systems. In this paper, we focus on flash IO patterns, that capture relevant distribution of IOs in time and space, and our goal is to quantify their performance. We define uFLIP, a benchmark for measuring the response time of flash IO patterns. We also present a benchmarking methodology which takes into account the particular characteristics of flash devices. Finally, we present the results obtained by measuring eleven flash devices, and derive a set of design hints that should drive the development of flash-based systems on current devices.
DENMARK
The paper is classified under mass storage, performance analysis, and design aids for flash devices.
- The paper concerns mass-storage design styles and performance analysis for flash devices.
- Its general terms are measurement, performance, and experimentation.
- Its keywords are flash devices, benchmarking, methodology, and uFLIP.
1. INTRODUCTION
The paper addresses how complex, undocumented flash devices should be understood and whether storage software must adapt to them. It proposes uFLIP, a methodology, and measurements of eleven devices to provide evidence for flash-system design.
- Flash devices combine chips, controllers, and proprietary software, making their behavior unlike that of the underlying chips and opaque to system designers.
- The central goal is to identify IOs or IO sequences that should be favored or avoided when designing flash-based systems.
- uFLIP is proposed as a benchmark that quantifies flash-device performance across relevant IO patterns in time and space.
- The benchmark must balance broad coverage, simple analysis, and methodology that accounts for undocumented, complex device behavior.
- Unlike earlier work focused on limited devices, database workloads, or ad-hoc methods, uFLIP studies varied IO patterns rather than one application domain.
- The paper defines nine IO-pattern micro-benchmarks, a flash-specific benchmarking methodology, and measurements across eleven devices ranging from low-end to high-end.
2. FLASH DEVICES
Flash devices expose a block interface over complex chip and controller layers, so IO performance depends on mappings, reclamation, device state, and request history. These properties motivate benchmarking IO patterns directly.
- uFLIP targets packaged flash block devices such as SSDs, USB drives, and SD cards, whose controllers expose the block abstraction.
- Flash chips store data in cells organized into blocks, pages, and sometimes sectors, with SLC and MLC technologies differing in density, speed, and lifespan.
- NAND flash reads and programs at page or sector granularity, while erases occur at block granularity, constraining write management.
- Planes and page caches provide internal parallelism that block managers can exploit to improve performance.
- The flash translation layer maintains direct and inverse LBA-to-page maps, trading faster reads against bookkeeping costs during writes.
- Writes are temporally non-uniform because updates create obsolete pages that later require reclamation.
- Because physical requests depend on direct-map state and prior IO history, benchmarking must control device state and request distributions in space and time.
3. THE uFLIP BENCHMARK
uFLIP reduces the large space of flash IO behaviors to nine micro-benchmarks built from parameterized IO patterns, then measures response times with portable, scalable experiments. Its detailed per-IO results require visualization and careful analysis.
- uFLIP is a benchmark for observing and understanding flash-device performance.
- It constructs relevant IO patterns from baseline patterns, functions, and parameters, then narrows the resulting space to nine micro-benchmarks.
- IO pattern attributes: Each IO pattern specifies submission time, size, logical location, and read-or-write mode.
- Pattern construction: The benchmark extends four baseline patterns—sequential reads, sequential writes, random reads, and random writes—with timing functions such as consecutive, pause, and burst.
- IO pattern attributes: Locations use sequential, random, ordered-increment, or partitioned functions, with alignment, offset, target-size, and shift parameters.
- Benchmark organization: Basic, mixed, and parallel patterns cover the design space, while experiments vary one parameter and micro-benchmarks organize related experiments.
- Benchmark organization: Runs record individual IO response times and summary statistics; nine micro-benchmarks vary parameters including IO size, alignment, target size, partitions, increment, pause, burst, ratio, or parallelism.
- Scope and analysis: uFLIP is portable across architectures, operating systems, and languages, and scalable across USB, SD, IDE, and SSD flash devices.
4. BENCHMARKING METHODOLOGY
The methodology addresses flash devices’ state dependence, time-varying response times, and interference between consecutive runs. It standardizes initial state, experiment duration, result summarization, run ordering, and host-side execution to obtain meaningful measurements.
- Device state: Flash-device state can make performance measurements meaningless, as random-write latency changed from about 1 msec to nearly 8 msec after filling a Samsung SSD.The out-of-box result was for 16KB random writes; after randomly writing the entire 32GB device, performance decreased by almost an order of magnitude.
- Device state: uFLIP assumes that completely writing the whole flash device produces a well-defined state because the block interface and black-box design prevent restoring factory settings directly.The benchmark enforces this state with random IOs across the device, while directing sequential writes to distinct target spaces to limit state disruption.
- Start-up and running phases: Experiments must ignore start-up IOs and include enough subsequent periods for stable statistics, because insufficient duration can underestimate average response time by about 25%.IOIgnore covers start-up, while IOCount covers enough running-phase periods for convergence; underestimating IOCount reduces precision and can produce incorrect results.
- Start-up and running phases: The benchmark models each run as a cheap start-up phase followed by a running phase whose response time typically oscillates among multiple values.Start-up costs may reflect delayed expensive operations such as buffering or lazy garbage collection.
- Run interference: Benchmark plans prevent cross-run interference by spacing runs, grouping sequential-write experiments with nonoverlapping target spaces, and inserting resets when accumulated target space exceeds device capacity.A pause is estimated by measuring how many sequential reads remain affected after a batch of random writes, though this is only an educated guess for unknown devices.
- Host-side effects: Direct synchronous IO bypasses host file-system, operating-system, and driver effects that would otherwise complicate interpretation of flash-device measurements.Direct IO bypasses the host file system, while synchronous IO avoids operating-system and driver parallelism.
5. FLASH DEVICE EVALUATION
uFLIP measurements reveal substantial device-dependent differences in flash IO performance, especially for startup behavior, granularity, locality, alignment, and write ordering. The results motivate concrete design hints favoring larger, aligned IOs, focused random-write regions, limited concurrent partitions, and careful device selection.
- Startup and running phases: About 125 IOs comprise the Mtron SSD random-write startup phase, followed by short-period oscillations that make startup-excluded averages more accurate.The running-average comparison is described for the RW baseline pattern.
- Startup and running phases: Random-write startup behavior separates tested devices: Memoright and Mtron show startup phases, while the other nine devices do not.For Memoright and Mtron, experiments with few random writes, especially mixed patterns, should scale the startup phase to the number of random-write IOs.
- Granularity and operation cost: On the Memoright SSD, reads and sequential writes have small latency, whereas large random writes cost at least 5 msec and alternate with erase operations costing tens of milliseconds.Small random writes are serviced faster, apparently because of caching; four 4KB writes take about as much time as two 8KB writes or one 16KB write.
- Alignment: Unaligned IOs can sharply degrade performance: on the Samsung SSD, unaligned random IOs increase response time from 18 msec to 32 msec instead of using 16 KB alignment.The broader design guidance is to align blocks to flash pages because the penalty for misalignment can be severe.
- Cross-device comparison: High-end SSDs substantially outperform other devices on basic IO patterns and cope better with reverse and in-place access patterns.The paper cautions that price does not always indicate relative performance, so high-performance systems should select devices carefully.
- Locality and concurrency: Random writes within 4–16MB typically perform nearly like sequential writes, whereas larger regions are usually expensive; concurrent sequential writes remain acceptable for 4–8 partitions but degrade beyond that.The benchmark also finds no benefit from parallel IO submission, and high concurrency can turn sequential writes into partitioned random-write patterns.
6. CONCLUSION
The paper positions uFLIP and its benchmarking methodology as a foundation for measuring flash-device performance and informing flash-based system design. It also identifies several directions for extending benchmarking and applying its findings.
- uFLIP and its benchmarking methodology are intended to provide a stable foundation for measuring flash-device performance.
- The benchmark specification, software, and results from eleven devices are made available to gather feedback from researchers and practitioners.
- Future work includes automatically tuning experiment lengths and generating benchmark plans, improving result visualization, and expanding the uFLIP website.
- The authors also identify opportunities to use knowledge from uFLIP for flash-device algorithm and system design.