Response
The fastest SSD we tested is slower than a hard disk
Four external SSDs, five enclosures and four cables, measured. The peaks were all capped by the link. The number that decided it is not on the box.
We needed to settle a boring question: which external drive and enclosure combination should we trust for large sustained writes. Disk images, bulk evidence copies and backup sets are all the same shape of work, a single very large write that has to finish and has to be readable afterwards. The marketing numbers were no help, because every drive on the shelf claims a figure it can only hold for a few seconds.
So we measured. Four drives, five carriers, four cables, one evening on a Mac, fio with --direct=1 and
iostat sampling every five seconds. Everything below is measured on the hardware in front of us,
not copied off a spec sheet.
The headline result: peak sequential speed was almost always capped by the link and told us nothing useful, while the sustained floors varied by roughly nine times between drives. The fastest device we tested is also the one we would trust least.
The floor is the number
Every consumer SSD writes into a fast SLC cache first and folds it down to slower flash in the background. Benchmarks that run for a few seconds only ever see the cache. Write more than the cache holds and you meet the drive’s real speed, which is the one that decides whether a 500 GB job finishes over lunch or overnight.
| Drive | Peak sequential write | Sustained floor | 300 GiB average |
|---|---|---|---|
| Kingston SNV3S1000G (USB4 enclosure) | 2,700 MB/s | 127 MB/s | 649 MB/s |
| WD PC SN810 (USB4 enclosure) | 1,603 MB/s | 1,124 MB/s | 1,457 MB/s |
| Samsung T9 (integrated, 20 Gb drive on a 10 Gb Mac port) | 780 MB/s | 918 MB/s, never drops | 963 MB/s |
| Orico USB drive (integrated, 10 Gb) | 776 MB/s | 195 MB/s under heat | ~425 MB/s |
Two notes on reading the table. The peak column is a short 8 GiB fio burst with direct I/O; the
sustained runs used buffered dd, which can come out higher on the same device. That is why the
T9’s floor sits above its peak. Both runs are hitting the same 10 Gb link, not the drive’s limit.
The averages are also slightly flattering, because dd reports finished about 20 seconds before
the last of the buffered data reaches the drive.
The Kingston is the fastest drive in the room right up until it is not. It held about 2,555 MB/s for roughly 280 GB, which covers most single transfers, then stepped down to 127 MB/s. That is slower than a mechanical hard disk. A 300 GiB write is about 322 GB, so the last 40 to 50 GB crawled through at 127 MB/s and took longer than everything before it. That is how a drive that spends most of the run at 2,555 MB/s ends up averaging 649. Cross that threshold on a 500 GB job and the projected time goes from about 6.6 minutes on the WD to about 32 minutes on the Kingston.
The Samsung T9 did something we did not expect: 918 MB/s dead flat across the entire 300 GiB, minimum 913, maximum 928, no cliff and no throttling anywhere. The T9 is a 20 Gb drive, but Macs do not support that USB mode, so it ran at 10 Gb. The link caps it below whatever the drive could really do, which means the link may be hiding a cliff rather than proving the drive has none. For practical purposes on a Mac it simply never slows down, which for unattended work is worth more than a higher number that only holds for the first minute.
The shape of the curve tells you which fault you have
Two very different problems produce a drive that starts fast and ends slow, and you can tell them apart from the curve alone without opening anything.
Cache exhaustion is one clean step that never recovers. The WD dropped from 1,524 MB/s to 1,132 MB/s between the 145 and 150 second samples and then sat at its new floor for the rest of the run, varying by less than 100 MB/s across ninety seconds. One step, no oscillation, no coming back.
Thermal throttling has multiple plateaus and it recovers. The passive Orico drive fell 863, then 700, then 445, then 195 MB/s in stages, and then climbed back to 695 MB/s while still writing. A cache that has run out does not refill mid-write. Only a controller that has cooled down speeds back up, so on a drive with clean free space, a mid-write recovery is almost always thermal. That drive also throttled after 55 seconds in the long run but held 863 MB/s for a full 71 seconds when run cold, which tells you the trigger is accumulated heat rather than bytes written. On a passive drive, the second transfer of the session will usually be worse than the first.
Cooling decided this outright. The fanless drive throttled to 23 percent of its starting speed inside a minute. A fan-cooled enclosure held full speed through an eleven minute continuous write with no sag at all.
The drive that broke, and how we worked out why
Partway through the evening the Kingston’s writes went erratic. Instead of a stable rate we got oscillation between roughly 120 and 940 MB/s, and a 60 GiB write that should have taken about 66 seconds was taking 137. Average throughput had halved.
The obvious suspect was a failing enclosure or a bad cable. It was neither, and four pieces of evidence pointed away from the transport:
- Two enclosures with completely unrelated bridge chips, one Realtek and one JMicron, produced the same erratic writes.
- Reads stayed perfectly stable on the same bridge in the same session. Sequential read varied with a standard deviation of about 6 MB/s, against about 300 MB/s for writes on that same connection. A flaky cable or bridge disrupts both directions. Only the write path was stalling.
- The degradation tracked cumulative writes, getting worse after every test rather than appearing and disappearing.
- Later, one run produced a curve that ran backwards: slow for 250 seconds, then full speed for 250 seconds, then slow again. Nothing thermal or cache related starts slow and speeds up. That is a drive with almost no free blocks, gradually freeing them as the write overwrites stale data.
The cause was TRIM, or rather the total absence of it. In the configuration we tested, ExFAT on a USB bridge, macOS issued no TRIM to any external drive at all. Every large test file we wrote and deleted stayed marked valid inside the drive’s flash translation layer. The controller believed it was nearly full, had almost no free blocks to fold into cache, and spent its time on garbage collection instead of writing.
The repair was a Windows quick format, which issues UNMAP across the volume and reaches the drive as an NVMe deallocate. Same enclosure, same test, before and after:
| Before | After | |
|---|---|---|
| 60 GiB write | 137.1 s | 66.3 s |
| Average | 470 MB/s | 972 MB/s |
| Curve minimum / median / maximum | 0 / 256 / 937 | 922 / 924 / 941 |
Twice the speed and completely stable. Then it degraded again after a single 300 GB transfer, which is the practical finding: this drive needs periodic maintenance from another operating system to stay usable, and one big write and delete is enough to undo it.
Before the confirming run we wrote down a prediction: about 920 MB/s flat for roughly 277 GB, then a single clean step to about 127 MB/s. Measured afterwards: 920 MB/s flat with a cache of about 280 GB, one step at 305 seconds down to a mean of 128 MB/s. Three of four predictions confirmed. The fourth, total run time, was wrong because we conflated GiB and GB, so 300 GiB is really 322 GB and there was more data left after the cache than we had allowed for.
What this does not prove. Three separate things all have to work for a delete on your desktop to free a block in flash: the filesystem has to emit the unmap, the transport has to carry it, and the drive has to care whether it arrives. The bridge carried UNMAP when Windows sent it, so the gap is on the macOS side, either in the filesystem or in macOS’s USB storage stack, and we could not separate the two. A different filesystem on a different carrier may well behave differently. The honest claim is that macOS issued no TRIM in this configuration, not that external drives never get TRIMmed.
It is also clearly not universal across drives. The Samsung T9 ran two consecutive 300 GiB writes forty seconds apart, with the first file deleted in between and no TRIM possible, and the second run was flat from its first sample and indistinguishable from the first. That is about 644 GB written to a maximally dirty translation layer with no measurable degradation. The Kingston is DRAM-less with a roughly 280 GB dynamic cache on a 1 TB drive, so free space essentially is its cache and losing the free space costs it everything. The T9 is not leaning on free space the same way.
Cables and enclosures do not behave the way the ratings suggest
We ran the same probe on one drive across four cables. Both Thunderbolt cables, the 40 Gb and the 80 Gb, came in about 15 percent slower than the manufacturer’s own plain USB-C cable, and landed within 2 MB/s of each other, which rules out one dud cable.
| Cable | Write | Read |
|---|---|---|
| Manufacturer USB-C | 790 MB/s | 813 MB/s |
| Second manufacturer USB-C | 784 MB/s | 813 MB/s |
| 40 Gb Thunderbolt | 676 MB/s | 708 MB/s |
| 80 Gb Thunderbolt | 674 MB/s | 701 MB/s |
All four negotiated the same link tier, so this is signal quality inside the tier, not a different tier. For a USB-only device the Thunderbolt rating is irrelevant, because the drive has no Thunderbolt controller and only the quality of the USB pairs matters.
Enclosures matter for a subtler reason. Two 10 Gb enclosures both reached about 940 MB/s on 4 MiB reads, so neither is broken. But at 1 MiB requests one delivered 803 MB/s and the other only 304 MB/s, because the second has far higher per-command overhead and needs very large requests to reach link speed. Real file copies mostly issue requests between 128 KiB and 1 MiB, which is exactly where it loses. A benchmark with a large enough block size would have called them equal.
Where this lands for security work
Two things carried over into how we handle drives on engagements.
Sustained floor is the specification that matters for imaging. An image is one enormous sequential write, so the number that decides whether it finishes is the floor, not the peak. A drive that collapses to 127 MB/s is not a drive you want holding an evidence copy overnight.
Wiping is not one thing. A full zero pass is a Clear in NIST SP 800-88 terms, and it defeats software recovery. It is not a Purge. Wear levelling means retired and over-provisioned blocks are not reachable through the logical address map at all, so no amount of writing zeros through the filesystem touches them. Purge needs a controller-level sanitize or crypto erase, which needs a carrier that passes NVMe admin commands through. Of the five carriers we tested, exactly one did. That is worth checking before you promise a client that a disposed drive is clean, because the enclosure in the drawer probably cannot do it.
Being wrong is part of the method
Nine of our working theories died during the evening. The 9,800 IOPS ceiling we assumed was an operating system limit turned out to be that particular drive’s own limit, because a second drive hit 15,700 through the identical path. A read speed we called a broken bridge was the drive thrashing on garbage collection, and it recovered after an idle period. A latency spike we blamed on an enclosure was the same clogged translation layer.
The pattern is consistent, and it is the same one we apply to security findings: a single observation almost always has more than one explanation, and the only way to tell them apart is to change one variable and measure again. If you do not test the second drive, you attribute the first drive’s limits to the whole platform, and then you buy the wrong thing.
What to do this week
If you move large amounts of data on and off external drives, three checks are worth an hour.
- Write a file larger than about a third of the drive’s capacity and watch the transfer rate the whole way through, not just the first thirty seconds. The number it settles at is your real speed.
- If the rate collapses and stays down after months of use, suspect the translation layer before the hardware, and try a full format from a system that actually issues TRIM.
- If you are relying on a wipe before disposal, confirm your enclosure can pass a controller-level erase. If it cannot, you have a Clear and not a Purge, and you should say so rather than assume.