The macOS Storage Speed Myth, Part 2: Unpacking Sequential vs. Random Access in the Age of Flash

In this installment of SSD explainers, we will crack the myth between sequential and random access.

The macOS Storage Speed Myth, Part 2: Unpacking Sequential vs. Random Access in the Age of Flash

Preface

You've probably heard that Solid State Drives (SSDs) are fantastic for "random" data access, a critical performance metric often lauded over traditional Hard Disk Drives (HDDs). But here's a surprising truth: when you really dig into how NAND flash memory works, the traditional concept of "random access" as we understood it with spinning disks doesn't truly apply. It sounds counter-intuitive, but understanding the underlying mechanics of an SSD reveals a more nuanced reality.

To grasp this, let's first revisit the origins of these terms.

What "Random" and "Sequential" Meant for Hard Drives

In the era of Hard Disk Drives (HDDs), "random" and "sequential" were distinct and crucial performance differentiators.

An HDD stores data on spinning platters, accessed by a mechanical read/write head.

  • Sequential Access: Imagine reading a large movie file stored contiguously on the disk. The read/write head barely moves, flowing smoothly from one sector to the next. This continuous, low-movement operation is fast and efficient.
  • Random Access: Now, imagine opening dozens of small files scattered across different parts of the disk. The read/write head must constantly "seek" (move) to new physical locations, incurring significant mechanical delays. This non-contiguous, seek-heavy operation is inherently slower, hence "random access" became synonymous with slower performance.

For HDDs, "sequential" meant reading/writing large, contiguous blocks without significant head movement. "Random" meant everything else – fragmented data, small, disparate requests, and constant head repositioning. This is where 99% of popular explanations about storage performance typically stop.

But SSDs are fundamentally different.

How SSDs Actually Work

SSDs ditch mechanical parts for semiconductor memory, specifically NAND flash. Understanding its structure is key:

  • Cell: The smallest unit, storing 1, 2, 3, or 4 bits of data (SLC, MLC, TLC, QLC, respectively).
  • Page: Comprised of many cells, a page is the smallest unit that can be read from or written to. Typical page sizes range from 4KB to 16KB.
  • Block: Many pages form a block. A block is the smallest unit that can be erased. Blocks are much larger than pages, often 256KB to 4MB.

The Flash Translation Layer (FTL)

Managing these microscopic storage units is the job of the Flash Translation Layer (FTL). This sophisticated mapping system resides within the SSD's controller and acts as a crucial intermediary between the operating system (OS) and the physical NAND.

The OS continues to request data using Logical Block Addresses (LBAs), a concept inherited from HDDs where data is seen as residing in contiguous logical sectors. The FTL's primary role is to translate these logical LBAs into the actual physical page and block addresses on the NAND.

Here are critical characteristics of the FTL that redefine "randomness" for SSDs:

  • Non-Linear Mapping: The FTL's mapping is highly non-linear. A file that appears logically contiguous to the operating system (e.g., LBA 1, 2, 3) will almost certainly be scattered across physically different pages, blocks, and even multiple NAND dies within the SSD. This is done for performance (parallelism), wear leveling, and garbage collection.
  • Parallelism (RAID-like): When you write a large file, the SSD controller doesn't just fill one block sequentially. Instead, it spreads the data across multiple NAND dies simultaneously, similar to how a RAID array stripes data across multiple hard drives. This massively parallel operation is why SSDs achieve such high overall throughput.
  • Overhead for FTL Lookups: While highly optimized and often cached in the SSD's DRAM, querying the FTL table still incurs a tiny amount of overhead for each unique physical address translation.

Given this non-linear, parallel, and distributed storage architecture, the traditional HDD definitions of "sequential" and "random" access become blurry. If a large file is always broken into smaller chunks and spread across the NAND for high-speed writes, is it truly "sequential" from a physical perspective? And if small files might coincidentally land on the same physical page or block, are they truly "random"?

Why "Random 4K" Performance Appears Slower

If the distinction between sequential and random is so blurred for SSDs, then why do benchmark tests consistently show "random 4K read/write" performance to be significantly lower than "sequential" performance? The answer lies not in how "random" data is accessed on the NAND itself, but in the nature of the requests and the fixed overheads involved.

Let's clarify some terms:

  • I/O Block Size (BS): This refers to the size of the data chunk being read or written in a single operation. For "sequential" benchmarks, this is typically large (e.g., 64KB, 128KB, 512KB or 1MB), often much larger than a single NAND page. For "random 4K" benchmarks, it's a small 4KB (or 8KB if being generous) chunk, almost always smaller than a NAND page.
  • Queue Depth (QD): This refers to the number of I/O requests the operating system sends to the SSD simultaneously. High queue depths mean many requests are "in flight" at once, allowing the SSD controller to optimize and parallelize operations.

Here's why small, "random" (low I/O block size) operations, especially at low queue depths, appear slower:

  1. Fixed Protocol Overhead: Every single I/O operation, regardless of its size, incurs fixed overheads:
    – The operating system needs to prepare the request.– The request travels over the NVMe (or SATA) protocol to the SSD controller.– The SSD controller processes the request, performs an FTL lookup, and communicates with its internal DRAM cache and NAND dies. This latency and processing cost is relatively constant per I/O.
  2. Payload Efficiency:
    – Large Sequential I/Os: When you perform a 1MB sequential write, you pay that fixed protocol overhead once for 1MB of data. This is highly efficient. The SSD controller then handles the parallel writes to NAND.– Small "Random" I/Os: When you perform a 4KB "random" write, you pay that same fixed protocol overhead for only 4KB of data. The efficiency plummets. It's like sending a huge truck to deliver a single envelope – the cost of the truck (overhead) is disproportionately high for the payload.
  3. Read-Modify-Write Penalty (for writes on a "dirty" drive):
    This is a critical factor for write performance, especially for small writes on an SSD that's been in use. NAND flash cannot be overwritten directly.
    If you want to modify data within an already-written page, the SSD can't just change that specific 4KB. It must:
    1. Read the entire block containing that page (e.g., 256KB or more) into its DRAM.
        2. Modify the specific 4KB data within that block in DRAM.3. Erase the entire original block.4. Write the modified data (the entire 256KB block) to a new, empty block. This "read-modify-write" cycle, also known as Write Amplification, is a major performance penalty for small, frequent writes to existing data, as it involves multiple internal operations for a tiny payload. A "fresh-out-of-box" (FOB) SSD performs better because all its blocks are empty and can be written to directly, avoiding this overhead until data accumulates.
  4. Queue Depth Mitigation: As you increase the Queue Depth (sending more small requests concurrently), the SSD controller can start to optimize. It might batch multiple small writes into a larger physical write operation, or parallelize the FTL lookups and NAND operations, thereby mitigating some of the per-I/O overheads. This is why the performance difference between "sequential" and "random" can diminish at very high queue depths.

In other words, the perceived slowness of "random 4K" operations on an SSD isn't primarily because data is "scattered" in the traditional HDD sense. It's a consequence of the disproportionate impact of fixed I/O overheads on tiny data payloads, compounded by the internal read-modify-write cycles required for writes on a "dirty" drive, especially when the SSD controller isn't given enough concurrent requests (low queue depth) to optimize its internal operations.

What Distinguishes Enterprise SSDs from Consumer SSDs?

Understanding the underlying principles of SSD performance helps us see where consumer-grade drives make compromises compared to their more robust enterprise counterparts. While a consumer SSD might offer impressive peak speeds, it often lacks the sustained performance and reliability features crucial for server environments.

Here's what so-called high-end consumer-grade SSDs often lack, explaining some of their limitations:

  • Minimal Over-Provisioning (OP): Over-provisioning is a hidden, reserved portion of the SSD's total physical NAND capacity, invisible to the user. This space is crucial for the SSD controller to efficiently perform background tasks like garbage collection, wear-leveling, and bad block management. Consumer SSDs often have little to no user-configurable OP, meaning the drive has less "breathing room" to manage data, which can lead to performance dips, especially when the drive is nearly full or under sustained heavy loads. Enterprise drives typically have significant OP (e.g., 7%, 28%, or even more) to ensure consistent performance and extended endurance.
  • Limited Controller Channels & Redundancy: Consumer SSD controllers might utilize fewer NAND channels (e.g., 4 channels instead of 8 or more). More channels allow the controller to communicate with more NAND dies simultaneously, increasing parallelism and raw throughput. Furthermore, enterprise SSDs often incorporate more robust controllers with features like redundant controllers or more advanced error correction codes (ECC) for higher data integrity and availability, which are generally absent in consumer models.
  • Firmware Not Optimized for Heavy/Steady-State Loads: Consumer SSD firmware is typically optimized for burst performance and typical client workloads, which involve short, intense periods of activity followed by idle times. This allows the SSD to use techniques like SLC caching to boost perceived speed. However, under sustained, heavy, or "steady-state" workloads (like those in servers or professional content creation), consumer firmware may struggle, leading to significant performance degradation as caches fill up and background operations become more frequent. Enterprise firmware is designed for consistent performance even under continuous, demanding I/O.
  • Constrained Power Consumption & Cooling System: High-performance SSDs, especially NVMe drives, can generate significant heat. Consumer SSDs often operate within strict power consumption limits (e.g., around 8-10W peak for M.2 drives) and rely on passive cooling (simple heatsinks or motherboard airflow). This limited thermal headroom means they are more prone to "thermal throttling," where the SSD intentionally reduces its performance to prevent overheating and damage. Enterprise SSDs often have higher power budgets and dedicated, more elaborate cooling solutions, allowing them to sustain high performance without throttling.
  • Consumer-Grade NAND: While 3D TLC or QLC NAND is now standard across both consumer and enterprise drives, enterprise drives sometimes utilize "eTLC" (enterprise TLC) or even MLC/SLC NAND. eTLC NAND, while still TLC, is specifically binned and selected for higher quality, better endurance, and more stable performance characteristics, especially regarding temperature and write latency. Consumer-grade NAND often prioritizes cost and density, making it less robust for extreme workloads or environments.

Conclusion: Understanding Real-World SSD Performance

In conclusion, the traditional "random vs. sequential" dichotomy, while crucial for HDDs, is a misleading framework for understanding SSDs. The inherent parallelism and Flash Translation Layer (FTL) of an SSD mean that data isn't truly "randomly" accessed in the mechanical sense.

Instead, the perceived difference in "random 4K" performance versus sequential performance boils down to:

  • I/O Block Size Efficiency: Small I/O block sizes (like 4KB) are less efficient due to the fixed protocol and controller overhead associated with each individual I/O operation. Larger block sizes amortize this overhead over more data, leading to higher throughput.
  • The "Dirty" Drive State and Write Amplification: As an SSD fills with data and undergoes deletions, it enters a "dirty" state. Subsequent writes to already-used logical addresses necessitate a Read-Modify-Write (RMW) cycle (reading an entire block, modifying the data in DRAM, erasing the old block, and writing the new block to an empty location). This is a form of Write Amplification, significantly impacting the performance of small, frequent writes. The more "random" (meaning, scattered across existing data that needs RMW) the logical write requests, and the dirtier the drive, the more frequently these costly RMW operations occur.
  • Controller and Firmware Optimizations: The capabilities of the SSD's controller, its power budget, cooling, and especially its firmware, play a monumental role. Enterprise SSDs are designed with generous over-provisioning, powerful multi-channel controllers, robust cooling, and firmware specifically optimized for consistent steady-state performance under heavy, sustained workloads. They actively minimize RMW cycles and manage background tasks to maintain high performance.

This is why software like HDTune's "sequential fill" tests, while useful for analyzing basic SLC cache behavior, cannot fully represent real-world performance. They often don't account for the sustained, mixed I/O patterns, various queue depths, and the "dirty" state that most client SSDs experience. In typical daily use, client SSDs operate in a lightly to moderately dirty state, where their performance is indeed heavily influenced by the lookup latency of less mature, DRAM-less controllers and the increased probability of costly Read-Modify-Write operations, particularly for small I/Os.

Ultimately, for optimal SSD performance, it's not about avoiding "randomness" in the HDD sense, but about understanding the efficiency of I/O operations and the internal workings of the flash memory, particularly as the drive ages and fills. As for the nice bandwidth number you see on the box? You probably won’t see it again after the SSD has been used for a while and reaching its max capacity.

References

[1] SNIA. “What is an SSD?

[2] Wikipedia. “Solid-State Drive.

[3] ATP Electronics. “How Over-Provisioning (OP) Enhances the Performance and Endurance of SSDs.

[4] TechTarget. “SSD Response Time.

[5] Kingston. “Difference Between Enterprise & Client SSD.