SMB Copy Speed Drops With Thousands of Small Files: What Should You Test First?

Test whether file count, not link speed, is the trigger before changing SMB or network settings.

On a home NAS, thousands of small files force the client and server to repeat path lookup, permission checks, opens, creates, metadata updates, closes, and application-side scanning for every object. A gigabit or 2.5GbE link can remain mostly idle while the copy still crawls, so the useful first step is an A/B test that keeps total bytes similar but changes object count, followed by storage, client, and copy-tool tests in a fixed order.

Compare One Large File With the Same Bytes in Small Files

Create two test sets on the same source storage: one large file and one folder containing thousands of small files with roughly the same total size. Copy both to the same NAS share using the same client, SMB path, and time window.

A TrueNAS user report shows the characteristic pattern of small-file SMB slowdown while large files remained near normal network speed. That contrast is more useful than a single speed number because it proves that the workload shape changes the bottleneck.

Record elapsed time, total files, total bytes, files per second, average MB/s, and whether the slowdown begins immediately or only after a cache fills. If both sets are slow, investigate the general network or storage path first; if only the small-file set collapses, continue with metadata-focused tests.

Separate Network Capacity From Per-File Work

Run a memory-to-memory network test between the same client and NAS, then compare it with the large-file SMB result. A clean network test and a fast large-file copy show that the link can carry data even though the small-file workload cannot keep it full.

Small files convert the copy into repeated request-and-response work. Eclectic Light documented how SMB metadata-heavy backups can take unexpectedly long even when little payload data moves.

Do not respond to that result by changing MTU, duplex, or link aggregation first. Track files per second and loaded latency instead; the next useful question is whether the repeated work is waiting on the source, the NAS destination, or client-side inspection.

Test Source and Destination Metadata Latency Separately

Copy the small-file set from the source into another local folder on the client, then create or extract the same set locally on the NAS. These two tests isolate source reads and NAS creates without SMB sitting between them.

A firsthand Unraid discussion measured slow per-file operations that were not visible during large-file transfers. The important signal is whether local destination creation is already slow before the network is involved.

If the client-local copy is slow, inspect the source disk, filesystem, encryption, and file layout. If NAS-local creation is slow, inspect the destination pool, cache tier, parity path, free-space fragmentation, metadata device, and synchronous-write behavior before tuning SMB.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Measure Security Scanning and Indexing on Both Endpoints

Antivirus, endpoint protection, thumbnail generation, content indexing, sync watchers, and media scanners may inspect every new file. Their fixed per-object cost can dominate a workload that creates thousands of items quickly.

Run one controlled test with real-time scanning and indexing temporarily excluded only for the dedicated test folder, then restore the protection immediately. The purpose is not to leave security disabled, but to determine whether the slowdown follows per-file inspection.

If files per second rise sharply, create a safer long-term exclusion only for trusted backup staging or generated cache data, or schedule the scan after the transfer. If the result does not change, restore the original settings and move to copy-tool behavior rather than accumulating unexplained exceptions.

Compare Copy Tools and Concurrency Without Changing the Dataset

File Explorer, Finder, Robocopy, rsync, backup clients, and archive tools can use different queue depths, metadata calls, retry rules, and parallelism. Compare two tools against the same source tree and destination rather than comparing unrelated workloads.

Resilio’s discussion of large file-count scans illustrates why a job may remain metadata-bound even when little content changes. More threads can hide some latency, but they can also overload the NAS with concurrent creates.

Increase concurrency one step at a time and stop when files per second stops improving, latency rises sharply, or the NAS begins queueing writes. Keep the setting that improves the real workload consistently, not the highest value the tool allows.

Use the Result Pattern to Choose the Smallest Fix

The diagnosis should point to one dominant stage: network capacity, source reads, NAS creates, endpoint scanning, SMB request behavior, or the copy tool. Do not combine all possible tunings into one experiment because the final speed change will no longer explain the cause.

ZimaSpace’s explanation of how file count increases NAS work provides the underlying reason that files per second can matter more than MB/s for this workload.

Accept the fix only when the same small-file set improves across repeated runs without harming large-file speed, permissions, restore behavior, or NAS responsiveness. When individual recovery is unnecessary, packaging immutable tiny files into an archive can reduce object overhead, but that is a workflow decision rather than a universal SMB repair.