Whether a full SLC cache comes back depends on how full the drive is, and in my idle tests it came back almost only on drives that were not full. On drives my write test had already filled to capacity, 30 minutes of idle brought back a median of 0GB. On drives with room left, the median was 125GB, about 53% of the cache. Among the full drives, only the Crucial P5 Plus 2TB got most of its cache back. Full drives were also faster, with a median burst of 5,870MB/s against 3,197MB/s. A second, smaller set of 31 drives from my second test bench points the same way. It belongs to the Flash Myths, Tested series.
Where the myth comes from
The speed on the box myth ends at the cache cliff. A TLC or QLC drive writes incoming data to part of its flash in SLC mode first, and when that part is full the write speed drops to a fraction of the burst. This myth takes the next step and says that once the cache has filled, the drive is slow from then on.
The opposite advice, that a drive recovers if you leave it alone, is common too, and it has a basis. A drive moves data out of the SLC cache into its permanent cells when it has nothing else to do, which Flash Foundations Part 6 calls folding. Kwon et al. describe the same arrangement for combined SLC and TLC flash in consumer devices, where data goes to the SLC buffer first and is migrated to the TLC region during idle time. Yang et al. found that in the drive they studied, the cache, about 65GB, was cleared during idle time.
Where the myth comes from
Idle time folds the cache into permanent cells
Clearing the cache isn’t the same as being able to use it again, and the second part is what a user feels. A drive can be done folding and still have no room to start a new cache, and that second question is the one I could test.
How I tested it
Every drive here ran the same write-saturation test that I describe in how I made SSD validation repeatable and used in the box-speed myth. It used sequential 1MiB writes at a queue depth of 32, straight to the raw disk, starting empty. That main run lasted between 15 minutes and about two hours depending on the drive. After it, the drive sat idle for a set gap, and then I ran another write for about 300 seconds.
How I tested it
A main run, an idle gap, then a write run counted at speed
The four gaps are named 30 seconds, 1 minute, 5 minutes and 30 minutes. Timestamps show the real gaps were 33, 63, 303 and 1,803 seconds on a typical drive. For each idle run I counted how many GB the drive wrote at speed, from the first fast row to the first confirmed drop. Fast means a smoothed write speed of at least 0.6 times that drive’s own burst speed from the main run. Dividing by the cache size the main run measured gives the share of the cache that came back.
I used the 55 drives whose main-run cache was at least 50GB. Four more drives had a cache under that. For them the first drop is a short dip, and an idle run can write several times more than that so-called cache, so I left them out. Three of the 55 have no 30-minute run, two that the main run filled and one that it didn’t. Their results at the other steps are included, and every count at 30 minutes below is out of the drives that have the run.
The split that matters is how many times the main run wrote the drive’s capacity. I call a drive full when the answer is 1 or more. Its run had written every address at least once, so the drive held a full drive of data when the idle tests began. This is my reading of the writes, because the archive doesn’t record how full the drive was. By that rule, 35 drives were full and 20 were not. The largest count was 13.68 times the capacity.
What came back
Figure 1 gives the median GB written at speed after each gap. For the full drives it is 0GB at every step. For the drives that were not full it is 30GB after 30 seconds, 42GB after 1 minute, 99GB after 5 minutes and 125GB after 30 minutes. Most of that median gain arrived within the first 5 minutes, but this is a median across drives, and single drives behave less tidily.
What came back
Idle time brought the cache back only on drives that were not full
Median GB written at speed in a 300-second run after each idle gap
Figure 2 shows the spread at 30 minutes. Of the 33 full drives with a 30-minute run, 19 wrote none of their cache at speed, 13 wrote under 25% of it, and one wrote more than half. That one is the Crucial P5 Plus 2TB, which the main run had written 1.39 times. It wrote 144GB at speed, 72% of its 200GB cache. Of the 19 drives that were not full and have the run, 10 got half or more of the cache back, the median share was 53%, and 2 got none.
What came back
Over half of the full drives got nothing back after 30 minutes idle
Drives by share of the main run’s cache written at speed after 30 minutes of idle
Four drives show how uneven single results are. Below is the GB each wrote at speed after each gap.
| Drive | Main run wrote | 30 seconds | 1 minute | 5 minutes | 30 minutes |
|---|---|---|---|---|---|
| WD Black SN770 2TB | 0.71 times the drive | 0GB | 17.1GB | 121.4GB | 346.8GB |
| Crucial P5 Plus 2TB | 1.39 times | 142.8GB | 147.4GB | 110GB | 144.2GB |
| Samsung 980 1TB | 0.55 times | 27.5GB | 53.2GB | 82.6GB | 0GB |
| Inland Prime 1TB | 0.91 times | 0GB | 0GB | 0GB | 0GB |
The SN770 is a slow comeback, with nothing after 30 seconds and almost half of its 714GB cache after 30 minutes. The P5 Plus is a full drive that got its cache back in 30 seconds, though it dipped to 110GB at 5 minutes before returning to 144.2GB. Samsung’s 980 rose for three steps and then wrote nothing at speed after 30 minutes, I can’t say why, because there is one run per step. Inland Prime wrote nothing at speed at any step even though the main run had not filled it.
What came back
Drives the main run had filled to capacity got little cache back
52 drives: cache back after 30 minutes of idle against how many times the main run wrote the drive
Figure 3 plots every drive with a 30-minute run against how many times the main run wrote it. Below 1 the drives scatter from none to more than twice their measured cache. Above 1 they sit almost all near zero. Some points are above 100% because the drive wrote more at speed in the idle run than the cache the main run measured, which says the main-run figure isn’t a hard limit. There is no clean line at 1. One drive at 0.91 got nothing back, and the full drives show no trend with more writes.
A second set of drives
After the first analysis I ran the same one on a second set of drives from a second test bench. Call the 55 drives above bench set A and these bench set B. Set B has 31 drives, with the same main write run, the same four idle gaps and the same count of GB written at speed. I keep the two sets apart and don’t pool them, because I only know the method is the same, not that the two benches are. Setup, drive preparation or room conditions could differ.
A second set of drives
In the second set too, only drives that were not full got cache back
Median GB written at speed after each idle gap, bench set B, 31 drives
Where the main run wrote a drive at least once over, 22 drives, the result is flat. None of them wrote anything at speed after any of the four gaps, so the median is 0GB at every step. Counts per step are 22, 21, 20 and 18 drives, because not every drive has every run. That includes all 7 of the PCIe 5.0 drives in the set. Three of them are retail drives of 1TB, 2TB and 4TB, which the main run wrote 10.23, 7.96 and 3.63 times, and each wrote 0GB at every gap.
Where the main run wrote under the capacity, 9 drives, some of the cache came back. The median was 0GB after 30 seconds, 14.6GB after 1 minute, 71GB after 5 minutes and 96GB after 30 minutes. Of the drives with the run, 5 of 9 wrote something at speed after 1 minute, 7 of 8 after 5 minutes and 6 of 7 after 30 minutes. This is the same shape as set A, with a lower median at 30 minutes (96GB against 125GB), and I wouldn’t read anything into that difference at these counts.
| Drive | Capacity | Main run wrote | 30 seconds | 1 minute | 5 minutes | 30 minutes |
|---|---|---|---|---|---|---|
| 28 | 1,000GB | 0.68 times the drive | 0GB | 35.7GB | 70GB | 110.5GB |
| 29 | 2,000GB | 0.75 times | 0GB | 50.1GB | 99.8GB | 143.1GB |
| 32 | 500GB | 0.48 times | 0GB | 21.1GB | 72.7GB | 95.7GB |
| 33 | 1,000GB | 0.78 times | 0GB | 0GB | no run | no run |
| 34 | 2,000GB | 0.64 times | 0GB | 50.3GB | 192GB | 294.4GB |
| 35 | 4,000GB | 0.79 times | 0GB | 14.6GB | 180.5GB | no run |
| 36 | 8,000GB | 0.32 times | 0GB | 0GB | 0GB | 0GB |
| 37 | 500GB | 0.92 times | 0GB | 0GB | 11.3GB | 11.3GB |
| 38 | 1,000GB | 0.87 times | 0GB | 0GB | 38.1GB | 36.2GB |
Set B has the same weakness as set A, but where set A’s was speed, set B’s is cell type. All 9 drives that were not full are QLC. Of the 22 full drives, 20 are TLC, one is QLC and one has no proven cell type. So in this set “not full” and “QLC” are almost the same group, and I cannot say which one lets the cache come back.
The one full QLC drive, which the main run wrote 1.26 times, wrote nothing at speed after 30 seconds, 1 minute or 5 minutes and has no 30-minute run. It’s one drive, and it fits the fill explanation better than the cell type one. Drive 36 is a not-full drive with nothing back at any gap, so the not-full group is not uniform either.
Speed class differs between the groups too, with the 22 full drives at 7 PCIe 5.0, 14 PCIe 4.0 and one with no recorded link, and the 9 that were not full are 5 PCIe 3.0, 2 PCIe 4.0 and 2 with no recorded link.
Set B is thin on one point. It has one run per step and the counts at 30 minutes are 18 and 7 drives. It agrees with set A and adds PCIe 5.0 drives to the picture. It does not add a test of one drive at two fill levels, which would settle the question.
Why a full drive may not get its cache back
Here I’m going beyond what I measured. Most SLC cache technologies size the cache from the amount of data stored on the drive, according to Yang et al.. Advantech’s white paper says the same in plainer terms, that the cache differs with the free space, so larger and less occupied drives can write more data at peak speed than smaller SSDs or drives nearing full capacity. My idle runs fit that. A drive can finish folding its cache into permanent cells, but a new cache has to be built out of free blocks, and a drive whose every address holds data has few to give.
Why a full drive may not get its cache back
A new cache is built from free blocks, and a full drive has few
My test also gives the drive no way to find free space. It wrote to the raw disk, so there was no file system and no TRIM, and the controller saw every address as valid once the main run had written it. The leave-space myth covers why that matters. I didn’t read any of these drives’ internal state, and I have no saved source that describes what these particular drives do after a run, so treat this as the explanation that fits the numbers.
The limits of this test
- Each idle run lasted about 300 seconds, so a number here is the GB written at speed within that window. I tested idle only up to 30 minutes. Nothing here says what an hour, a night or a week of idle does.
- Full and fast are tangled. Each drive’s main run lasted a similar time, so a faster drive wrote the capacity more times. Median burst speed was 5,870MB/s in the full group and 3,197MB/s in the group that was not full, and 31 of 35 full drives ran on PCIe 4.0 against 13 of 20. I cannot separate “this drive was full” from “this is a faster drive”. Measuring one drive at two fill levels would, and I do not have that.
- The fill is a raw-disk fill. A drive that is nearly full of files with TRIM working is not the same as a drive whose every address was written, and I did not test it.
- There is one run per step. Results aren’t steady from step to step on single drives, as the table shows.
The limits of this test
A faster drive writes the capacity more times and counts as full
What to do with this
If you copy several hundred GB at a time to a drive that has plenty of free space, a pause of a few minutes between jobs gave back part of the cache on many of these drives, and a pause of 30 minutes gave back half or more of the cache on 10 of the 19 drives that were not full. A pause is no guarantee, and 2 of those 19 got none.
If the drive is close to full, don’t count on a pause to restore the burst. Of the full drives, 19 of 33 got none of their cache back after 30 minutes, and the median was zero at every gap. The sources and these numbers point to free space. Keep room on a drive that takes big writes, and use TRIM Check to confirm the drive is told what is free.
What to do with this
Free space decides whether a pause brings the cache back
For reading reviews, look for a test that writes past the cache, and for any test that writes a second time after a pause. One tells you the speed after the cliff, and the other is the only way to see whether the drive came back.
