Bits and bytes, and the mistake that follows
Network speed is quoted in bits per second and file sizes are quoted in bytes, and the factor between them is eight. A gigabit link is 1000 megabits per second, which is 125 megabytes per second, and that is before any protocol overhead. Real file transfers over such a link land somewhere near 110 to 118 megabytes a second depending on the protocol and the conditions, which is what the efficiency field is for.
Once that conversion is in front of you, a lot of arguments resolve themselves. A single modern mechanical drive sustains more than 125 MB/s on its outer tracks. A single solid state drive is several times that. So an eight-drive array attached to a gigabit link is not an eight-drive array as far as anyone copying a file is concerned; it is a gigabit link with a lot of capacity behind it. Adding drives to that arrangement buys space and redundancy and does not buy speed.
Where the bottleneck actually moves
With the defaults on this page, six data drives at 180 MB/s each and 80 percent array efficiency come to 864 MB/s, against a gigabit link delivering about 115. The drives are capable of more than seven times what the network can carry. Move to a 10 Gb link and the same array becomes the limit instead, at which point drive count and drive speed start mattering again and the efficiency figure earns its place.
That crossover is the useful thing to know before spending money, because the two upgrades are not interchangeable. If the link binds, faster drives change nothing. If the array binds, a faster switch changes nothing, and the person who upgraded the network and found the copy took exactly as long is a common enough story to be worth predicting rather than experiencing.
| Link | Bits per second | Bytes per second, line rate | Realistic file transfer |
|---|---|---|---|
| 1 Gb | 1,000 Mbps | 125 MB/s | Around 110 to 118 MB/s |
| 2.5 Gb | 2,500 Mbps | 312.5 MB/s | Around 280 to 295 MB/s |
| 5 Gb | 5,000 Mbps | 625 MB/s | Around 560 to 590 MB/s |
| 10 Gb | 10,000 Mbps | 1,250 MB/s | Around 1,120 to 1,180 MB/s |
The right-hand column is the line rate multiplied by an efficiency figure, not a promise. Whether you reach it depends on the protocol, the client, the cabling and what else is on the path, and the slowest link in that path is the one that counts. An uplink between two switches, or one old cable in a wall, sets the number for everything behind it regardless of what the ends are capable of.
Small files, and why archiving first is faster
Sequential throughput describes one large file moving. It describes a folder of ten thousand small files very badly, because each file costs its own open, metadata read, transfer and close, and those costs are paid per file rather than per byte. The result is a per-byte rate that can be a tenth of the sequential figure or worse, and it gets worse still as latency between the two ends rises.
Put twenty percent of the bytes into small files at fifteen percent of the large-file rate and the effective throughput for the whole job falls by roughly half, which is far more than twenty percent of anything. That arithmetic is why packing a directory into a single archive before moving it is frequently quicker overall even after paying for the packing and unpacking, and it is worth measuring on your own share rather than assuming either way.
Several clients on one share
The ceiling is shared, and dividing it evenly by the client count is a convenient fiction. What actually happens is that whichever client asks hardest gets more, and the others experience the shortfall as latency rather than as a tidy fraction of the throughput. For a backup job that is fine. For someone editing video off the share it is not, because a stall matters more than an average.
Work out what each client genuinely needs rather than what it would like: video editing needs the bitrate of the format divided by eight, so a 200 Mbps format is 25 MB/s, and a backup job wants whatever it can get and should be limited on purpose. The backup window calculator covers how much time a limited backup then needs, and the household bandwidth calculator covers the same contention problem where it crosses the internet connection instead of the local network.
What this does not cover
Sequential throughput is the easy half. Random access, many small operations at once, and latency all behave differently, and an array that streams a file beautifully can feel slow under a database or a virtual machine because the workload is not sequential at all. If the share is backing virtual machines, that is the number that will matter and it is not this one; the capacity side of that question is on the VM host capacity calculator.
Cabling and switching set the ceiling before anything else does. What a run can carry and how far is on the ethernet drop calculator, and if any part of the path is wireless then wireless is the answer to every question on this page, which the access point coverage calculator and the channel width planner deal with directly.
Questions people ask
How fast should a gigabit connection copy files?
A gigabit link is 125 megabytes per second at line rate, and real file transfers land somewhat below that because protocol framing, headers and acknowledgements all consume some of it. Somewhere in the region of 110 to 118 MB/s is what a healthy gigabit path tends to produce on large files with a common file sharing protocol, and the efficiency field on this page exists so you can put in whatever your own measurement shows rather than accepting any figure. If you are getting far less than that on large files, the problem is in the path rather than in the arithmetic: a duplex mismatch, a bad cable, an old switch, or one wireless hop in the middle.
Will more drives make my NAS faster?
Only if the drives are the bottleneck, and on a gigabit link they almost never are. One modern drive can already saturate that link, so a six-drive array and a two-drive array copy a large file at the same speed and the difference is capacity and redundancy rather than throughput. On a 10 Gb link the picture changes and drive count starts to matter, because the array becomes the limiting side. The calculator shows both numbers side by side so you can see which upgrade would actually change the one you care about.
Why does copying a folder of small files take so much longer than one big file of the same size?
Because the cost is per file as well as per byte. Every file needs to be opened, have its metadata read and written, be transferred and be closed, and each of those steps involves at least one exchange between the two machines. Ten thousand files means ten thousand sets of those exchanges, and if each round trip costs even a millisecond the overhead dwarfs the actual data. This is also why the effect gets dramatically worse over a link with higher latency. Packing the folder into a single archive first converts the job back into a sequential one, which is often faster overall despite the extra step.
Is 2.5 Gb enough, or should I go straight to 10 Gb?
That depends on the array behind it, which is exactly what this page is for. If the drives can only deliver 300 MB/s, a 2.5 Gb link at roughly 290 MB/s is already close to fully using them and 10 Gb would be capacity you cannot fill. If the array can deliver 800 MB/s, 2.5 Gb throws most of it away. Enter both sides and look at which number is smaller; the upgrade worth making is the one that moves the smaller number. Bear in mind that the whole path has to support the speed, so a fast card at each end with an older switch between them runs at the switch speed.
How do I know what throughput my drives really do?
Measure it rather than trusting a specification, because the specification is a best case that applies to part of the drive. Mechanical drives are significantly faster on their outer tracks than their inner ones, so a nearly full drive is slower than an empty one for reasons that have nothing to do with fragmentation. Solid state drives often sustain a high rate until a write cache fills and then drop sharply, so a short test overstates them. Copy something large enough to run for a couple of minutes, and do it directly on the storage rather than across the network so you are measuring one thing at a time.