Skip to content

CONCEPT Cited by 1 source

QLC read-vs-write asymmetry

Definition

QLC read-vs-write asymmetry is the property — intrinsic to Quad-Level-Cell NAND physics — that reads complete substantially faster than writes on the same media. Meta's 2025 framing: "Read throughput in the case of QLC can be as high as 4x or more than write throughput."

Root cause: storing 4 bits per cell requires programming the cell to one of 16 voltage levels with high precision (slow, iterative write); reading only requires distinguishing which of the 16 levels the cell is at (fast, parallel). The asymmetry widens with bits-per-cell; TLC (3 bits, 8 states) has a smaller gap, QLC (4 bits, 16 states) has a larger one.

The architectural problem

Reads in data-center workloads are typically latency-sensitive (user-facing query, cache fill, analytic scan). Writes are typically async / bulk (compaction, ingest, flush).

If a read arrives at a drive that is currently writing, naïve FIFO queueing stalls the read behind the slower write — introducing tail latency that defeats the read-bandwidth reason QLC was deployed in the first place.

Meta's statement:

"Typical use cases around reads are latency sensitive so we need to make sure that the I/O delivering this massive read BW is not getting serialized behind the writes. This requires building, and carefully tuning, rate controllers and I/O schedulers."

The response: software arbitration

The rate-controller pattern:

  1. Classify each I/O as read or write, latency-sensitive or bulk.
  2. Cap the concurrent write budget at a fraction of the drive's write capacity that preserves headroom for reads.
  3. Prioritise reads in the queue, or split read/write queues served by different scheduling policies.
  4. Pace writes so they don't burst into a queue depth that blocks reads.
  5. Tune empirically per workload and per QLC part — published read/write asymmetries vary by vendor, die generation, controller.

Why it can't be fixed at the drive

Modern SSDs expose a single queue per namespace. The kernel / host cannot "see" which of the queued operations are running vs deferred inside the drive — the drive may itself interleave writes and reads, but its policy is vendor-fixed and not application-aware.

This is one of the load-bearing arguments for userspace FTL as a pattern: moving flash management into host-side software gives the host-side scheduler full visibility + control of the write queue, which is necessary to do effective R/W arbitration under the QLC asymmetry.

Extends across media

The general problem — media with asymmetric read/write throughput serving mixed workloads — recurs at many altitudes:

  • HDD: random writes are cheaper than random reads (pagecache absorbs), but neither is "fast". Asymmetry is small.
  • TLC flash: mild asymmetry (~2× at most).
  • QLC flash: 4×+ asymmetry → requires explicit host-side arbitration.
  • Future PLC (5-bit cells): will widen further.

Each tier down the bits-per-cell axis inherits more of this problem.

Seen in

Last updated · 319 distilled / 1,201 read