SMB copy drops from 110MB/s to 8MB/s after the first two gigabytes Help

If it comes back after the scrub, look at one disk in particular. Run a long SMART test on each and watch the pending sector count. A single failing drive drags the whole array down to its speed and often shows no errors in the pool status until much later.

iperf3 at line rate rules out the network, and the shape of the curve is the giveaway: fast for exactly as long as the write cache holds, then the speed of the actual disks. Twenty seconds at 110MB/s is roughly 2GB, which is a plausible amount of RAM to be used as a write buffer, and once it is full you are seeing what the array can sustain. 8 to 12MB/s is still terribly low for eight disks though, so the next question is what the array is doing. Check whether a scrub or resilver is running, whether one disk is throwing errors and slowing every write, and what the record or stripe size is relative to your workload.

Test with a single 40GB file rather than a folder of mixed sizes as a control. Lots of small files over SMB is a protocol overhead problem, not a disk problem, and the fix is different.

Also worth checking whether the destination dataset has compression or encryption doing something unexpected, and whether the source is a spinning disk that is itself slowing. Half the time the bottleneck is on the machine nobody suspects.