SSD performance degradation when a disk fills: tests and rules

Why a full SSD starts to feel slow without obvious signs

"Freezes" are often blamed on the internet, Windows updates, antivirus or "not enough RAM." But when a drive is nearly full, symptoms look very similar: apps take longer to open, the browser hesitates, copying many small files is jerky, and the system can hang for 5–20 seconds without a clear cause.

The paradox is that an SSD can be fast "in benchmarks" and still feel slow in daily use. Many benchmarks measure short, neat operations and show nice numbers while there is spare free blocks and a cache. In real life the drive is constantly handling small writes: temp files, browser caches, updates, logs, mail databases, messenger data. On a nearly full SSD those writes more often become "expensive" operations. This doesn’t show up as a constant low throughput but as rare, annoying pauses.

For an SSD, "full" is not only "90% used." What matters is how many gigabytes are free, how fragmented that free space is into small "holes," how often background writes occur (updates, sync, caching), and whether the drive has internal spare area for its own needs.

What inside an SSD affects speed drop when it fills

An SSD looks like a "fast disk without mechanics," but inside it follows NAND memory rules. When free space is low those rules start to hurt performance.

Pages, blocks and why you can’t just "overwrite a file"

SSD memory is layered: writes happen in small chunks (pages), but erasing is possible only in much larger units (blocks). If a small file changes, the controller often cannot erase and rewrite just that piece. Typically it:

• writes the new version of data elsewhere,
• marks the old pages as "stale",
• later consolidates them and erases the whole block.

While free space is plentiful this is almost unnoticeable. When space is tight the drive has to move data more often and latency increases.

Free space, TRIM and garbage collection

TRIM is a command from the OS that tells the SSD: "these data are deleted, you can prepare those blocks for erasure." Without TRIM the drive is worse at knowing what is truly free and spends more time reclaiming space.

Garbage collection is the SSD’s background work: it copies live pages, frees blocks and prepares space for new writes. When the disk is full this gets harder because there’s little room to temporarily relocate data.

SLC cache: why it’s fast at first and then suddenly slow

Many SSDs speed up writes using an SLC cache: part of the memory temporarily operates in a faster mode. While the cache has room, write speeds are high. During a large continuous write the cache fills and the drive falls back to native NAND speed, which is noticeably lower. If the disk is nearly full, the cache and temporary operations have less spare area and the slowdown happens sooner.

So speed drops are often stepped: first everything is fast, then it becomes 2–5 times slower, and at very tight capacity there can be another drop. This is normal SSD physics, not a quirk of a particular model.

What to measure so comparisons are fair

A single "speed test" run easily leads to wrong conclusions. For a fair comparison conditions must be identical and metrics understandable.

1. How to describe fill level. Percentages are convenient, but "10% free" on a 256 GB drive is different from 10% on a 2 TB drive. Record both percent and absolute gigabytes (for example, 85% used and 75 GB free).

2. Workload type. An SSD can look fast on large sequential files and drop sharply on small random operations typical for office work (mail, browser, messengers, 1С database, updates). For a realistic picture keep at least three profiles: large files, small files, and mixed workload.

3. Conditions that break repeatability. Temperature and power saving change speed by tens of percent, and background tasks (antivirus, indexer, updates) can consume random I/O. Before each run check SSD temperature, power mode, free space (in % and GB), background processes and use the same amount of test data.

4. Number of runs. One run often shows a "lucky" peak. Do at least 3 cycles and look not only at the mean but at the variance. If at 90% fill one run is twice slower than the others, real use will include similar unexpected pauses.

Preparation for testing: safety and basic settings

The test should not end with data loss. When filling and freeing large amounts of files you increase risk if the drive already has issues.

Back up important data (work documents, mail, databases, app profiles). For office PCs with accounting, medical systems and other critical tasks, run experiments on a test machine or a separate drive rather than on the only system disk.

During measurements stop things that quietly "steal" disk time: background updates, cloud sync, full antivirus scans, heavy scheduled tasks. Otherwise you’ll measure OS activity, not the SSD.

Before starting check basic health and operating mode:

• TRIM enabled.
• SMART with no errors or warnings (especially reallocated, media errors, CRC).
• Controller operating in the correct mode (AHCI/NVMe), no unusual errors in Device Manager.
• Close applications that actively write to disk (torrents, video recording, messengers with large caches).

For repeatability note the environment: OS version and build, key drivers (chipset, NVMe/SATA), power mode and, if available, SSD firmware version.

If the system disk is already nearly full, Windows will aggressively use temp files and swap and results will be noisy. It’s more practical to keep at least 15–20% free on the system disk and do fill tests on a separate partition or a second SSD.

Measurement scenarios: a simple matrix by fill level

To see when an SSD begins to sag you need measurements under the same conditions but at different fill levels. Four scenarios are enough: baseline, several fill points, a long write and "real-life" actions.

Fill points that give a clear picture

• Scenario A: "clean" disk. Baseline — how the drive behaves with plenty of free space.
• Scenario B: 70%, 85%, 90% and 95% full. Differences often appear in jumps: latency grows around 85–90% and sustained write throughput drops at 95%.

At each state repeat the same short set: sequential read/write and random read/write. Look at typical values, not the single best run.

Long write and mixed tasks

• Scenario C: long write for 20–60 minutes. This captures the drop after SLC cache exhaustion: the first minutes are fast, then speed falls and may fluctuate.
• Scenario D: mixed operations. Copy a 20–50 GB folder, install 2–3 apps in sequence, extract an archive, run a system update. Here time-to-complete and pauses (for example, Explorer freezing 2–5 seconds) matter more than MB/s.

In all scenarios record average and minimum speeds (especially in long writes), operation times, SSD temperature and any throttling events.

Step-by-step: test at the office without a lab

The goal is simple: find at which fill level the SSD loses speed and becomes uneven. You can do this on a regular office PC if you keep conditions consistent.

Prepare test data

Use a dataset of 50–150 GB (scaled to disk size) so copying takes noticeable time. A mixed set is best: one folder with large files (video, images, archives) and one with many small files (documents, mail, many small files). Keep the folder structure identical for each run.

Create fill points and measure

1. Make fill levels (70%, 85%, 90%, 95%). Fill the drive with ballast of large files without touching system folders.

2. At each level run short tests: 1–2 minutes of writes, 1–2 minutes of reads (any familiar tester), plus two practical actions — copy a large 10–20 GB file and copy a folder of small files.

Record not only average speed but behavior: are there drops to tens of MB/s, does preparation time for copy increase, does Explorer freeze?

3. Add a long write for sustained throughput: write a large volume sequentially (for example, 50–100 GB as a single file). This often reveals what happens after the fast buffer is gone.

4. Repeat each scenario 2–3 times and take the median. Give the PC 5–10 minutes idle between runs so background tasks don’t skew results.

5. Find the tipping point: where speed becomes unstable or operation times jump. That’s the practical threshold after which it’s simpler to clean or plan expansion.

Free-space thresholds: practical rules for different roles

A filling SSD slows gradually, and it’s easy to miss until everyday tasks stall. To avoid surprises, keep a clear free-space buffer.

How much free space to keep

The busier the disk, the more buffer you need:

• system SSD (office, browser, mail): 15–20% free;
• home/general PC: around 20%;
• workstation (video, CAD, large archives): 25–30%;
• disks for databases, logs, virtual machines: 30% and up.

If the SSD is under 512 GB, don’t rely only on percentages: keep a minimum of 50–80 GB free.

Buffer for updates and temporary files

Windows has invisible expenses: updates, rollbacks, temp files. A sensible minimum for smooth updates is 20–30 GB free plus room for browser and messenger caches and working folders like Downloads.

Tell‑tale signs are mundane: copying the same file takes longer, updates hang at "preparing," apps start noticeably slower, free space falls in jumps. If this coincides with dropping below your chosen thresholds, start by freeing space rather than hunting for mysterious causes.

Common mistakes in testing and interpreting results

The main trap is believing the "pretty" peak numbers reflect all-day behavior.

Mistake 1: trusting peak speed

A benchmark often shows a high speed initially while the SLC cache works and the drive is cool. During large copies speeds can fall after 30–120 seconds. What matters is stable speed after warm-up, not the maximum.

Mistake 2: testing a system disk that’s full to the brim

When the system disk has almost no free space the OS interferes: temp files have nowhere to go, swap behaves poorly, and freezes or errors can occur. To measure the drive, leave the OS some buffer.

Mistake 3: ignoring temperature and power mode

Overheating and power profiles change results dramatically. Keep identical conditions: same power plan, similar temperature and the same test durations.

Mistake 4: drawing conclusions from a single run or a single test

Do 3 runs and look at variance. Compare at least two workload types: short responsiveness tests and long writes (post-cache behavior).

Mistake 5: changing connection and not recording it

A USB enclosure vs direct connection, a different M.2 slot, another controller mode, or an old driver — all affect results. Log any change to the test bench alongside numbers.

Quick checklist: how to tell the SSD is hitting capacity limits

If you see microfreezes without a clear cause, lack of free space on the SSD is a common culprit. You can check this in 10–15 minutes without benchmarks and without risking data.

Five quick checks

• How much free space is left on the system disk (where Windows and apps live).
• What’s taking the space: Downloads, Desktop, Videos/Photos, Recycle Bin.
• Temp files and caches: browser, messengers, office apps, system temp folders.
• Growth over 30–90 days: big installs, updates, logs, bloated user profiles.
• Write behavior: copying halts in bursts, extracting archives is noticeably slower, updates take ages.

Signs it’s time to act

It’s time to clean or expand if updates fail for lack of space, apps freeze during saves/downloads, or free space regularly falls below comfortable levels. What you can do in 15 minutes safely: empty Recycle Bin, clear Downloads, remove temp files with OS tools, move large personal files off the system disk. Then reboot and check free space again.

Real example: an office PC that started to "freeze"

In an accounting department there was a standard office PC (compact workstation like GSE L200): mail, 1С, scans of documents, Excel, Windows updates and antivirus. The 512 GB SSD had been OK for a long time until it quietly reached 90–95% full.

At first complaints were vague: "it sometimes lags." Later it got clearer: apps opened slower, saving mail attachments had delays, updates took hours. Worst of all, during background writes the PC could pause for 5–20 seconds as if frozen.

To verify, they measured in two states with the same tester and conditions (closed extra apps, waited 10 minutes after boot, repeated 3 runs).

Results were clear:

• at 92% full: random 4K writes noticeably dropped, sequential writes stuttered, updates took nearly twice as long;
• after cleaning to ~25–30% free: tests stabilized, freezes nearly disappeared, updates and archive extraction sped up.

The fix wasn’t a one-time cleanup but process: move heavy scans and archives to a network share, limit local caches and schedule expanding storage before fill returns past 85–90%.

Policy: when to clean and when to expand — simple rules

To avoid "mystery slowdowns" put a simple policy in place: who monitors free space and when you stop cleaning and start increasing capacity.

Start by separating the system SSD from project and archive storage. Then set a routine and thresholds:

• check free space monthly (or weekly for busy stations);
• warning threshold: below 20% — move data or clean up;
• decision threshold: below 10–15% — plan expansion rather than endless cleaning;
• responsibility: a named IT person or owner for each PC/department;
• archiving: projects older than N months go to archive.

Expanding is often faster and cheaper than endless cleaning if teams repeatedly hit the red zone, if projects grow and moving data takes hours, or if many files can’t be relocated (mail, databases, app caches). Plan capacity for 12–24 months: measure growth over 3–6 months, multiply for 4–8 quarters and add 20–30% for peaks. Standardizing configurations across purchases simplifies support and forecasting. When buying in batches, set a minimum SSD size per role. In this area it helps to consult the vendor or integrator who understands typical loads; for example, GSE.kz selects and supplies workstations and servers and supports infrastructure where disk issues regularly surface.

Next steps: lock in the rule and avoid returning to the problem

If you’ve already measured, use those results as an internal benchmark: at what fill level do your typical tasks start taking noticeably longer?

Put the results in a simple table: fill level, boot time, time to open 2–3 heavy files, copy time for a 10–20 GB folder and a short note about freezes. Then choose thresholds that fit your work.

How to enforce the rule in a company

• Approve free-space thresholds: "yellow" (clean/move) and "red" (expand/replace) for different PC types.
• Set regular checks: weekly for critical stations, monthly for others.
• Add 2–3 time-based control operations (e.g., launch mail, open the database/spreadsheet, copy a test folder) and check them on schedule.
• Assign an owner: who reviews reports, who decides, who cleans or upgrades.
• Define "cleaning": remove temp files, move archives to server, clear Downloads, move media.

A simple rule: if the red threshold occurs twice in a row or free space is consumed faster than it can be freed, it’s time to increase capacity.

Considerations when renewing hardware

For office, education and medical PCs build in capacity buffers: data profiles grow differently. When procuring, choose SSDs and support options so you don’t return to space shortages 6–12 months after deployment.