SLC Cache Exhaustion: Why Your SSD Slows Mid-Copy

Copy a 60GB video project onto a brand-new NVMe drive rated at 7000MB/s sequential write, and somewhere around the 25GB mark the transfer speed collapses to 400-800MB/s. This is not a faulty drive, a bad cable, or a Windows caching quirk. It is SLC cache exhaustion, and it is the single most misunderstood bottleneck in consumer and prosumer storage today. Every mainstream TLC and QLC NAND drive on the market relies on a pseudo-SLC write buffer to hit its advertised throughput numbers, and every one of those buffers has a hard capacity limit. Once you exceed it, you are writing directly to native multi-level cell NAND at a fraction of the speed, and the marketing spec sheet becomes irrelevant.

This article breaks down the controller-level mechanics behind the cliff, how to measure it deterministically rather than anecdotally, and where it intersects with thermal throttling, garbage collection, and DRAM-less design choices that most buyers never account for when selecting storage for a workstation or NAS build.

#The Sustained Write Cliff: Where Marketing Numbers Diverge From Reality

Manufacturer datasheets quote sequential write speed measured against an empty drive writing into an empty SLC cache. That number is real, but it is only valid for the first few gigabytes of any given transfer. The moment the cache fills, the flash translation layer (FTL) has two options: stall incoming writes while it flushes cached pages to native NAND, or accept writes directly into TLC/QLC blocks at their native (much lower) programme time. Either path produces the same symptom from the host’s perspective — a sudden, often violent, drop in throughput.

The scale of the drop depends entirely on NAND type. Native TLC programming runs at roughly a third of SLC speed per cell, because TLC stores three bits per cell and requires three separate voltage-threshold passes to resolve a value, against a single pass for SLC. QLC drives, storing four bits per cell, suffer worse — native QLC write speed on budget drives can fall below 100MB/s, which is slower than a SATA HDD in sequential mode. If you are provisioning storage for video editing, VM image staging, or bulk log ingestion, the sustained write rate after cache exhaustion is the only number that matters, not the headline burst figure.

#Architectural Breakdown: How Dynamic SLC Caching Works

#Pseudo-SLC Emulation on TLC/QLC Dies

Pseudo-SLC (pSLC) caching does not use dedicated SLC silicon on consumer drives — that died out with early enterprise Optane-adjacent designs. Instead, the controller instructs a subset of TLC or QLC blocks to store only a single bit per cell, ignoring the additional voltage states the cell is physically capable of holding. This gives you SLC-equivalent write speed and endurance on a fraction of the die’s normal density, at the cost of consuming three to four times the physical capacity per logical gigabyte cached.

Controllers implement this in one of two allocation strategies:

• Static SLC cache: a fixed partition, typically 3-6% of total capacity, permanently reserved regardless of drive fill level. Predictable but small.
• Dynamic SLC cache: the controller allocates free TLC/QLC blocks as pSLC on demand, meaning cache size shrinks as the drive fills with user data. A 2TB drive might offer 200GB of dynamic pSLC cache when empty, but only 10-15GB once the drive reaches 85% capacity.

This is why the exact same drive model, benchmarked empty versus benchmarked at 80% capacity, produces two entirely different sustained write results. Any review that only tests an empty drive is measuring a best-case scenario that most real-world users will rarely experience after the first few months of use.

#DRAM, HMB, and the Controller’s Mapping Overhead

The controller’s ability to manage SLC cache exhaustion gracefully depends heavily on whether it has a dedicated DRAM package for the flash translation layer’s mapping table, or relies on Host Memory Buffer (HMB) borrowed from system RAM over the NVMe protocol. DRAM-less drives using HMB introduce additional PCIe round-trip latency for every mapping lookup during the flush-and-write cycle that occurs at cache exhaustion, compounding the throughput collapse. This is a core reason why budget DRAM-less NVMe drives exhibit sharper, more erratic cliffs than their DRAM-equipped counterparts — the controller is simultaneously fighting NAND programme latency and mapping-table lookup latency with no local buffer to absorb either.

These design decisions are not cosmetic; they represent genuine architectural patterns trade-offs between bill-of-materials cost and sustained performance predictability, and they should factor into procurement decisions the same way CPU cache hierarchy factors into compute sizing.

#Implementation Logic: Diagnosing SLC Cache Exhaustion Deterministically

Anecdotal “it slowed down during a big copy” reports are not sufficient for capacity planning. You need a repeatable methodology that isolates the cliff point and measures both pre- and post-exhaustion throughput.

1. Secure-erase or fully fill the target drive to the capacity state you want to test (empty, 50%, 85%) — cache behaviour is capacity-dependent, so test at the fill level representative of production use.
2. Run a sustained sequential write workload well beyond the expected cache size — for a 2TB consumer drive, sustain writes for at least 100GB.
3. Sample instantaneous throughput at fixed intervals (every 1-2 seconds) rather than reporting an averaged final figure, which masks the cliff entirely.
4. Cross-reference the throughput drop against controller temperature and NVMe SMART log attributes to distinguish SLC cache exhaustion from thermal throttling — the two frequently overlap and are easy to misattribute.
5. Repeat at multiple drive fill levels to build a cache-size-versus-capacity curve, which is the only reliable way to predict real-world behaviour on an aged, partially-full drive.

#Code and Configuration: Benchmarking the Cliff

Use fio with a large sequential job and short per-sample logging intervals to capture the transition point precisely. Averaged bandwidth figures from a single summary line are not granular enough to locate the cliff.

1fio --name=slc_cliff_test 
2 --filename=/dev/nvme0n1 
3 --direct=1 
4 --rw=write 
5 --bs=1M 
6 --iodepth=32 
7 --numjobs=1 
8 --size=120G 
9 --time_based 
10 --runtime=600 
11 --log_avg_msec=1000 
12 --write_bw_log=slc_cliff 
13 --group_reporting

The --write_bw_log flag produces a per-second bandwidth CSV (slc_cliff_bw.1.log) that plots the cliff directly — you will see a flat high-throughput plateau followed by a sharp step down once the pseudo-SLC allocation is consumed.

Correlate the fio timeline against controller-reported temperature and media wear using the official nvme-cli toolset, which exposes vendor-specific SMART attributes that generic tools like smartctl often omit for NVMe devices:

1nvme smart-log /dev/nvme0n1
2
3# Key fields to watch during the sustained write test:
4# temperature                       : 78 C
5# percentage_used                   : 3%
6# data_units_written                : 41213291
7# controller_busy_time              : 184
8# warning_temp_time                 : 12

A rising warning_temp_time counter during the test indicates thermal throttling is compounding the SLC cache exhaustion cliff, not causing it independently — a distinction that matters when deciding whether a heatsink retrofit will actually recover lost throughput.

To estimate effective dynamic cache size from the log without manual inspection, a short awk pass against the fio bandwidth log finds the index where bandwidth drops below 60% of the initial plateau:

1awk -F, '
2 NR==1 { peak=$2 }
3 { if ($2 > peak) peak=$2 }
4 $2 < (peak*0.6) && !found {
5 print "Cliff detected at sample " NR ", elapsed(ms)=" $1;
6 found=1
7 }
8' slc_cliff_bw.1.log

#Failure Modes and Edge Cases

SLC cache exhaustion rarely occurs in isolation. Several compounding failure modes turn a predictable performance dip into a genuine reliability or data-integrity concern.

Garbage collection contention: once the cache is exhausted, the controller must simultaneously service incoming host writes and relocate previously cached pSLC data back into native TLC/QLC form (a process called folding). On drives with weak background GC scheduling, this produces write amplification spikes and can push sustained throughput even lower than steady-state native NAND speed for several seconds at a time — visible as sawtooth patterns rather than a clean step-down in the fio log.

Thermal throttling overlap: M.2 drives without a heatsink frequently hit their thermal ceiling at almost the exact point dynamic cache exhausts, because sustained high-current NAND programming is itself a major heat source. Diagnosing which factor dominates requires the temperature correlation shown above; applying a heatsink to a drive whose bottleneck is purely cache-size-driven will not recover the lost throughput.

RAID and ZFS rebuild scenarios: a rebuild or resilver operation is a sustained, long-duration sequential write by definition. If the array uses consumer drives with small dynamic caches, every member drive will hit its cliff simultaneously, and the array’s rebuild time will be governed by native NAND speed, not the drive’s rated specification. This is a frequent and avoidable cause of rebuild windows running two to three times longer than capacity-planning spreadsheets predicted.

DRAM-less drives under HMB starvation: if the host system is under memory pressure and the OS reclaims HMB-allocated pages, DRAM-less drives lose access to their mapping-table cache mid-transfer, producing an additional latency spike layered on top of the SLC cache exhaustion cliff. This is most commonly observed on laptops running memory-hungry VMs alongside large file transfers.

Near-full drives: because dynamic cache allocation borrows free blocks, a drive above roughly 90% capacity may have almost no pSLC cache available at all, meaning every write — even a small one — hits native NAND speed immediately. This is functionally indistinguishable from a failing drive to an untrained observer, and is a common source of unnecessary RMA requests for drives that are simply full.

#Scaling and Security Trade-offs

Procurement decisions around SLC cache exhaustion touch endurance, encryption overhead, and long-term capacity planning simultaneously.

• Static vs dynamic cache endurance: static pSLC partitions wear evenly and predictably across their fixed lifetime; dynamic caches shift wear across the entire die population, generally improving whole-drive endurance but making per-block wear-levelling harder to model for warranty-lifetime planning.
• Encryption overhead at the cliff: AES-256 hardware encryption engines on modern controllers rarely add measurable latency to SLC-cache writes, but during native TLC/QLC programming — already latency-bound — encryption pipeline stalls become proportionally more visible, occasionally adding 3-5% additional throughput loss post-cliff on lower-tier controllers.
• Over-provisioning trade-off: manually reserving 10-20% of a drive’s logical capacity (leaving it unpartitioned) increases the pool of free blocks available for dynamic pSLC allocation, directly enlarging the effective cache at the cost of usable capacity — a worthwhile trade for editing or database staging volumes.
• Enterprise vs consumer NAND economics: enterprise NVMe drives frequently use true SLC or high-endurance MLC with minimal or no pseudo-cache dependency, trading raw capacity-per-dollar for flat, predictable sustained write curves — the correct choice for write-heavy database or logging workloads where a cliff is operationally unacceptable.
• Array-level scaling risk: striping consumer SSDs in RAID 0/5/6 multiplies aggregate cache capacity linearly while sustained cliffs still occur simultaneously across members, meaning array-level sustained throughput can drop by the same percentage as a single drive, not average out — a frequently overlooked assumption in capacity planning documents.

Understanding where the pseudo-SLC boundary sits on a given drive model, and how it shrinks with capacity fill, turns an apparently unpredictable performance regression into a fully modelled and provisioned-for characteristic of the storage layer.