Why Does Free-Space Fragmentation Slow a Home NAS Before It Is Full?

A home NAS can slow before it is full because the remaining free space may be plentiful in total yet difficult to allocate in useful contiguous runs.

Deletes leave holes of different sizes across the pool. New files, copy-on-write updates, parity stripes, and snapshots cannot always reuse those holes efficiently. The allocator spends more time searching, large writes split into more extents, and the capacity gauge still looks comfortable because it counts free bytes rather than their shape.

The Pool Runs Short of Useful Extents Before Free Bytes

Free-space fragmentation describes how available capacity is distributed. Ten gigabytes in one region is not equivalent to ten gigabytes divided into thousands of narrow gaps when a workload wants long sequential extents. The allocator may satisfy both requests, but the fragmented version creates more mappings and less predictable physical locality.

This is why used percentage and fragmentation are separate signals. The pool capacity and fragmentation properties report different aspects of the same storage state; neither number alone predicts application latency.

Deletes Create Holes That New Writes Cannot Always Reuse

A deleted file returns its extents only when no snapshot, clone, or open reference still owns them. Even then, the new write may require different alignment or a larger run. Small freed regions can be suitable for metadata while remaining poor matches for a large archive or database extent.

As the set of choices narrows, an allocator may shift from quick selection toward more expensive searching. OpenZFS describes how low free-space conditions change allocation behavior in its free-space and allocation guidance. The exact threshold is implementation-specific, so a fixed percentage should be treated as an operating margin, not a universal failure line.

Copy-on-Write Makes the Free-Space Map Age Differently

Copy-on-write does not overwrite an existing block. It allocates a new location, writes the changed content, updates metadata, and releases the old location only when nothing else references it. This preserves snapshots and crash consistency, but repeated modification can scatter new versions across the pool.

A clear copy-on-write explanation connects immutable old blocks with new allocation, while a filesystem design note on long-term copy-on-write fragmentation shows why the layout can become less sequential as updates accumulate. Snapshots can extend that period by keeping old extents unavailable for reuse.

HDDs and SSDs Expose Different Parts of the Problem

On an HDD, fragmented extents directly increase mechanical seeks, so a large file may read far below its original sequential rate. SSDs remove head movement but not allocator searches, mapping changes, metadata traffic, or internal flash cleanup. Fragmentation can therefore remain a latency problem even when the device has fast random reads.

Parity and compression add further constraints because storage may allocate around stripe boundaries or variable compressed records. Research on fragmentation in large-object storage demonstrates that object size and update pattern matter together. A benchmark based only on an empty pool cannot represent this aged allocation state.

Capacity Headroom Is an Allocation Resource

Free space gives the allocator choices. More choices make it easier to place a growing file in longer runs, distribute copy-on-write updates, and absorb maintenance without immediately reusing narrow holes. That is the engineering reason behind leaving headroom; it is not merely a warning about the final byte.

Do not turn the common 80 percent recommendation into a law. A reader-facing analysis of pool headroom and allocator behavior is useful context, but a home NAS should be judged by its actual fragmentation metric, snapshot retention, workload, device layout, and latency trend. Rising allocation time before full capacity is the observable warning.

FAQ

Can deleting one large file defragment a NAS pool?

It can create a useful large free extent if no snapshot retains the blocks, but it does not reorganize existing files or guarantee that future allocation will remain contiguous.

Is free-space fragmentation the same as file fragmentation?

No. File fragmentation describes one file split across extents. Free-space fragmentation describes the shape of unallocated regions. The two influence each other but can move independently.

Will an SSD eliminate the slowdown?

It removes mechanical seek cost, not filesystem allocation, metadata, copy-on-write, parity, or flash garbage-collection overhead. The symptom may shrink or shift toward tail latency rather than disappear.