DEV Community: lowspecai

The cheapest SSD that won't die in a NAS

lowspecai — Fri, 23 Oct 2026 16:44:40 +0000

Most home NAS builds do not die of a bad drive. They die of a cheap drive in the wrong slot, on a machine that loses power without warning.

I run two machines from 2011 as NAS boxes. One is a laptop board: Celeron B815, two cores, 4 GB of DDR3, a 100 Mbps port, a 256 GB SATA SSD and a 320 GB 5400 rpm drive. The other is a mini PC with an i5-2520M, 8 GB, gigabit, a 128 GB SSD and a 3 TB WD Red Plus. Neither is fast. Both have been through enough failures that the drive advice I would give now is the opposite of what the spec sheets sell.

This is the short version of a longer guide I keep on my own site, with the numbers measured on those two boxes.

The endurance maths nobody needs

A 500 GB TLC drive rated at 300 TBW. A busy home NAS writes maybe 5 TB a year — Immich thumbnails, container logs, a backup target, some downloads. 300 ÷ 5 = 60 years. Even with 3× write amplification from a copy-on-write filesystem you are still past 20.

TBW is a warranty term, not a lifespan prediction. The 256 GB drive in the small box reports 8 power-on hours, 0 reallocated sectors, wear-levelling count 0. Nothing about its flash is anywhere near tired. What it lacks is any protection against being unplugged mid-write.

So stop shopping on endurance. It is not the constraint.

What actually kills them

Power loss on a drive with no power-loss protection. Capacitors that flush the write cache on power loss exist only on enterprise drives. Consumer drives — including the expensive ones — do not have them. A DRAM-less drive keeps its mapping table in an on-chip buffer, and losing that mid-write is how you get a filesystem that needs a rebuild instead of a reboot. On a single-drive box that is an afternoon. On an array it can take the whole thing.

The SLC cache running out. Cheap QLC drives benchmark beautifully for the first few gigabytes, then collapse to tens of megabytes per second once the pseudo-SLC cache is exhausted. That is slower than the hard drive you were replacing. Copying 40 GB of photos onto a fresh QLC drive is exactly the workload that finds this.

Heat. A 2.5" SATA drive with any airflow at all is fine — mine sits at 45 °C. An M.2 stick bolted behind a drive cage with no airflow will throttle silently and then start dropping off the bus.

The bridge, not the drive. Cheap USB enclosures and add-in SATA controllers fail more often than the disks inside them. The 3 TB drive in the larger box accumulates interface error counters while completely idle, at roughly 0.1 per second, and the count does not grow with I/O volume. That is firmware or link behaviour, not a dying platter. When a drive misbehaves, suspect the cable, the enclosure and the controller before you blame the NAND.

What I measured

Measurement	Number	What it tells you
Sequential read, 256 GB SATA SSD (`hdparm -t`)	506 MB/s	the drive is nowhere near the bottleneck
Sequential write, 3 TB WD Red Plus (`dd`, `conv=fsync`)	107 MB/s	a good 5400 rpm-class platter
Buffered read, 320 GB 5400 rpm notebook drive	88 MB/s	what the SSD replaced
SMB transfer over the onboard 100 Mbps port	11.4 MB/s up, 11.3 MB/s down	the real ceiling of that machine
Web UI first load, before and after the SSD swap	24 s → 0.25 s	a 100× win with nothing to do with bandwidth

Read that table twice. The SSD moves data about 45 times faster than the network port feeding it. A drive with 10% more sequential bandwidth would have changed nothing anyone could perceive.

The 100× improvement came from queue depth, not throughput. The 5400 rpm drive choked on a few dozen concurrent small reads — the JavaScript, the CSS, the fonts — and each one waited behind the last. An SSD serves them in parallel. That is the whole mechanism, and it is why the cheapest drive with a DRAM cache already delivers it.

Practical consequence: once you are on an SSD, paying more for a faster SSD buys nothing measurable on a home NAS. Pay for the two things that do not show up in a benchmark — a DRAM cache and a printed TBW — and stop there.

Five lines on the spec sheet

DRAM cache. The datasheet says "DRAM" or names a cache size. If it says nothing, assume none. DRAM-less drives lean harder on the host and degrade faster as they fill.
TLC, not QLC. Capacity per dollar is the QLC pitch and it is the wrong trade for a machine that receives bulk writes. Shortcut: at the same capacity, a QLC drive's TBW is usually about half of a TLC drive's.
A TBW number that is actually printed. A manufacturer that omits it is telling you something.
Power-loss protection — or an admission that there is none. Consumer drives do not have it. This line decides whether you need a UPS, not whether you need a pricier drive.
SMART attributes that are exposed. A decent drive reports reallocated sectors, pending sectors, uncorrectable errors, UDMA CRC errors and total bytes written. Cheap USB bridges hide all of them, so you cannot see a drive dying until it is dead.

The configuration I actually run

System disk: a small TLC SATA SSD with a DRAM cache, 240–512 GB. OS, container images, databases. Nothing else.
Data disk: a mechanical drive, CMR not SMR, btrfs or ext4. Photos, media, documents, backups.
The SSD never holds cold data. A drive that is only read from does not need to be fast, and a platter gives far more capacity per unit of money and per unit of risk.
Check for SMR before buying a big 2.5" drive. Many high-capacity portable drives are shingled and fall out of an array during a rebuild — exactly when you cannot afford it.

Unglamorous, and it is what both boxes do. The SSD absorbs everything random and small; the platter absorbs everything sequential and large.

Three commands before you trust a drive

# 1. sequential read, bypassing the page cache
sudo hdparm -t --direct /dev/sdX

# 2. the SMART attributes that matter
sudo smartctl -A -d sat /dev/sdX

# 3. 4K random read - the closest thing to a real NAS workload
sudo fio --name=r4k --rw=randread --bs=4k --iodepth=32 --size=1G --runtime=30 --filename=/dev/sdX

I have run the first two on my own drives. I have not run the third on the drive that is in production, so I am not going to invent a number for it — the command is the honest part of that section.

What matters in the SMART table:

5 Reallocated_Sector_Ct — anything above zero, stop putting new data on it.
187 Reported_Uncorrect and 197 Current_Pending_Sector — same rule.
198 Offline_Uncorrectable — same rule.
199 UDMA_CRC_Error_Count — climbing means the cable, backplane or bridge, not the NAND. Replace the cheap part first.
241 Total_LBAs_Written — a sanity check on how much life has actually been used.

The cheapest reliability upgrade is not an SSD

The larger box died three times in ten days. The drive was not the cause. The kernel is configured not to reboot on a panic, and the hardware watchdog is disabled, so when the machine hangs it hangs forever instead of recovering.

The third time, the smart plug it is plugged into reported 40 W. Idle is 20 W. Power was still flowing — the machine had not lost power, it had stopped responding, and I cut the plug to restart it from another room.

Every one of those events was an unclean shutdown in the middle of writes to an SSD that has no power-loss protection and never will. So the arithmetic is simple: a cheap drive plus a UPS is more reliable than an expensive drive without one. If your budget covers only one, buy the UPS.

If you cannot buy a UPS, at least do this: enable "Restore on AC Power Loss" in the BIOS, and put the box on a plug you can switch remotely. A laptop used as a NAS has this built in — mine has a 43 Wh battery that turns a power cut into a non-event.

What I would not buy

No-name drives with no TBW and no SMART. You cannot monitor what you cannot see.
QLC marketed on cache speed. The benchmark is real; the workload that follows it is not the one they tested.
Used enterprise drives with 50,000 power-on hours. The remaining life is unknowable and the seller knows it.
A USB enclosure as permanent storage. Controllers drop off the bus, and a btrfs array that loses a device mid-write is a bad afternoon.
An M.2 drive with no airflow in a case designed for platters.

Numbers above were measured on the two machines described at the top; anything from a vendor spec sheet is labelled as such. Original, with the full method and the failing-drive history: lowspechq.com. That page carries one clearly labelled affiliate link to an SSD listing; nothing here is sponsored, and no seller saw this text before you did.

Tokens per second is a memory bandwidth number. Measure it in 2 seconds.

lowspecai — Fri, 23 Oct 2026 03:49:06 +0000

A 40B model that does 125 tok/s on a laptop, and a 7B model that does 1.5 tok/s on a 2011 CPU with the same amount of RAM. Same ballpark of memory, ~80× difference in speed. Almost every explanation you will read for that gap is wrong, and the wrong explanation costs people money.

Here is the number that actually decides it: how many bytes your machine can read per second. Not cores. Not GHz. Not TOPS.

The formula

Generating one token with a dense model requires reading the entire set of weights once. Every token. There is no caching trick around it — the weights do not fit in cache, so each token is one full sweep of DRAM.

tokens/second  ≈  memory bandwidth  ÷  bytes of weights read per token

That is the whole ceiling. Everything else — kernel quality, quantization, --threads — decides how close you get to it, never how far above it you can go.

I measured the bandwidth on my own box

The machine is an Intel i5-2520M from 2011 running as a NAS. 8 GB of DDR3-1600, one DIMM, nproc 4. Not a benchmark rig; it is the thing serving files in the other room.

import numpy as np, time

mb = 512
a = np.ones(mb * 1024 * 1024 // 4, dtype=np.float32)

a.sum()                                  # fault the pages in first
ts = []
for _ in range(5):
    t = time.perf_counter()
    a.sum()                              # read-only, no write traffic
    ts.append(time.perf_counter() - t)

print(f"{mb / 1024 / min(ts):.2f} GB/s read")

Results:

Array	Read-only (`sum`)	Copy (`copyto`)
256 MB	8.98 GB/s	4.76 GB/s
512 MB	9.04 GB/s	4.74 GB/s

Three things worth noticing.

First, the copy number is not the bandwidth number. A copy reads each byte and writes it, so it moves twice the traffic for the same wall time. 4.7 GB/s of copying is ~9.5 GB/s of DRAM traffic — which is the same wall the read pass keeps hitting. If you benchmark with memcpy and compare it directly against a model's tok/s, you will be off by a factor of two and conclude your machine is magically twice as fast as physics allows. Use a read-only pass.

Second, 9.0 GB/s against a theoretical 12.8 GB/s for single-channel DDR3-1600 is 70% of peak. That is a healthy result. Old hardware is not secretly broken; it is just narrow.

Third, adding threads does not add bandwidth. Same 256 MB arrays, one thread per array, min of five runs:

Threads	Aggregate	Per thread
1	8.8 GB/s	8.8 GB/s
2	10.2 GB/s	5.1 GB/s
4	10.6 GB/s	2.7 GB/s

It plateaus at ~10.5 GB/s and stops. On a dual-channel board four threads would have gone well past that — two channels of DDR3-1600 is 25.6 GB/s of theoretical peak, and you would expect to reach most of the way there. I get about 40% of it. So: one DIMM, and the DIMM is the ceiling, not the core count. Confirm it on your own box with sudo dmidecode -t memory | grep -E "Size|Locator|Speed|Rank" before you spend anything.

What that predicts, and what it does not

Plug the measured 9.0 GB/s in:

Weights per token	Theoretical ceiling	What you should expect in practice
4.4 GB (7B at Q4_K_M)	2.0 tok/s	1.2 – 1.6 tok/s
8.0 GB (13B at Q4)	1.1 tok/s	0.7 – 0.9 tok/s
23 GB (40B at Q4)	0.39 tok/s	0.24 – 0.31 tok/s, and it will not fit in 8 GB

Real-world runs land at 60–80% of the ceiling. If you are seeing 1.5 tok/s from a 7B Q4 model on hardware like this, your setup is fine and there is nothing left to tune. If you are seeing 0.2 tok/s, something is wrong — usually it is swapping, not compute. On an 8 GB machine with 5.1 GB actually available, a 4.4 GB model plus the OS is right at the edge; the moment the kernel starts paging, you are no longer measuring DRAM bandwidth, you are measuring your SSD.

Now the 125 tok/s claim

I have not run Flint 40B, so I am not going to tell you it is fake. I am going to tell you what has to be true for the number to be real.

At 23 GB of weights per token, 125 tok/s requires 2,875 GB/s. Nothing portable has that. The fastest laptop memory shipping today is in the several-hundred-GB/s range. So a 40B model at 125 tok/s is not reading 23 GB per token — which means most of its parameters are not being touched for a given token. That is what mixture-of-experts buys you: 40B parameters resident, a couple of billion active. Divide the active set instead of the whole model and the arithmetic works out fine.

This is the actual shift in 2026's local models, and it is worth internalising: parameter count stopped being the thing that sets your speed. Active bytes per token is. A "40B" MoE can be several times faster than a "13B" dense model while using more RAM. Benchmarks that report only total parameters tell you nothing about tok/s.

The table you actually want

Bandwidth by machine, and the ceiling it implies. Only the first row is measured here; the rest are stated figures with a 75–85% efficiency factor applied, which is why they say "est."

Memory	Stated	Effective (est.)	7B Q4	40B Q4	40B MoE, ~2 GB active
DDR3-1600, 1 channel — measured here	12.8 GB/s	9.0 GB/s	2.0	0.39	4.5
DDR3-1600, 2 channels	25.6 GB/s	~19 GB/s	4.3	0.83	9.5
DDR4-3200, 2 channels	51.2 GB/s	~38 GB/s	8.6	1.7	19
Laptop LPDDR5	~120 GB/s	~90 GB/s	20	3.9	45
Discrete GPU, 288 GB/s	288 GB/s	~245 GB/s	56	11	122

Read this table before you buy anything. Then read it again.

What it changes about buying hardware

Three practical consequences, in order of how much money they save.

1. The cheapest upgrade on an old box is a second DIMM. My machine is single-channel. Adding a matching stick roughly doubles the read bandwidth, and therefore roughly doubles tok/s — for a part that costs less than a month of coffee. Check first:

sudo dmidecode -t memory | grep -E "Size|Locator|Speed|Rank"

One "Size: 8 GB" line means single channel. Two matched lines means dual. This is a bigger lever than any CPU you can put in the socket.

The caveat, and it is the reason this advice does not help me: if both slots are already populated you cannot add a channel, only replace the pair with larger sticks — same bandwidth, more capacity. Bandwidth is a property of the channel count, not the DIMM size. So the question to answer before shopping is how many slots are free, and dmidecode answers it in the same output.

2. A CPU upgrade buys you almost nothing for generation. My CPU is thermally degraded — it hits its 86 °C throttle line about three seconds into a sustained load and settles at 1.7–2.0 GHz, below its 2.5 GHz base clock. It has already given up 20–30% of its rated clock. Token generation does not care, because the cores are idle waiting on DRAM. Prefill (processing your prompt) is compute-bound and does care; the first ten seconds of a long prompt will get faster. Steady-state chatting will not.

3. If you want 40B-class dense models at conversational speed, you are buying bandwidth. That means a machine with wide memory — an Apple Silicon laptop, or a GPU with fast VRAM. Not a faster CPU, not more cores, not more RAM of the same narrow kind. More RAM lets you fit a bigger model; it does not make it faster.

That is the whole thing. Measure your read bandwidth, divide by the size of the weights, and you know what your hardware is going to do before you download 20 GB over your home connection.

Reproduce it

The snippet above is the entire method — numpy, five runs, minimum. It takes two seconds on any machine and it is more informative than any spec sheet.

If you want the shopping side of this — which used mini PCs actually have two DIMM slots and what they cost — I keep that list here: Best mini PC for running Ollama under $300. I also wrote up which cheap SSDs survive in a NAS, because the "it started swapping" failure above is exactly how people kill a consumer drive.

How this was made: drafted with AI assistance, which I am stating up front rather than leaving you to guess. The memory benchmark was run by me on the machine described above, and every number in the first two tables is a command you can re-run in two seconds. The Flint 40B figures are from the vendor's announcement — I have not run that model, and the arithmetic in that section is presented as arithmetic, not as a benchmark. The two links at the end point to my own site, which carries affiliate links that are labelled as such on the page.