Why This Matters More on Linux
Linux will boot off an HDD just fine, but you’ll feel every second of it. The kernel itself loads fast regardless of drive, but init systems, systemd service ordering, and desktop environments like GNOME or KDE all hammer the disk with small random reads during boot. That’s exactly the workload HDDs are bad at. An SSD doesn’t just make Linux feel faster, it removes an entire category of stutter that shows up as “disk is 100% busy” in iotop or htop.
If you’re setting up a new install, running VMs, compiling anything larger than a toy project, or using Btrfs/ZFS with snapshots, the drive choice stops being a nice-to-have and starts being the thing that determines whether the machine feels usable.
As an Amazon Associate we earn from qualifying purchases at no extra cost to you.
The Core Numbers
Forget marketing bullet points, these are the numbers that actually show up in daily use:
| Metric | 7200 RPM HDD | SATA SSD | NVMe SSD |
|---|---|---|---|
| Sequential read | 120-180 MB/s | 500-560 MB/s | 2,000-7,000+ MB/s |
| Random 4K read (QD1) | 0.5-1.5 MB/s | 30-40 MB/s | 40-80 MB/s |
| Typical access latency | 8-15 ms | 0.1 ms | 0.02-0.05 ms |
| Boot to login (Linux desktop) | 25-45 sec | 8-12 sec | 5-8 sec |
| Cost per TB (2024-ish) | $15-25 | $40-60 | $50-90 |
The random 4K row is the one people skip over and shouldn’t. Package managers, git operations, compiling with lots of small object files, and the Linux filesystem journal itself are all random-write-heavy. That’s where HDDs fall apart, not in big sequential copies.
Filesystem Choice Changes the Equation Too
If you’re running Btrfs or ZFS with copy-on-write and snapshots, you’re generating a lot more small random I/O than ext4 would for the same workload. On an HDD this gets painful fast, snapshot-heavy Btrfs setups on spinning disks can visibly lag during normal use. On an SSD it’s a non-issue because random I/O is cheap. If you want snapshots and rollback (useful before kernel or driver upgrades), pair that filesystem with an SSD, not a hard drive.
Swap behavior matters too. Swapping to an HDD is brutal, you’ll get multi-second freezes under memory pressure. Swapping to an SSD is tolerable, though you still want enough RAM that you’re not relying on swap constantly, since SSDs do wear from writes over time.
Where HDDs Still Make Sense
I’m not going to pretend HDDs are obsolete, because for specific roles they’re still the right call:
- Bulk storage and media libraries. If you’re storing a few TB of video, backups, or ISOs that get read sequentially and rarely, an HDD does the job at a third of the cost per terabyte.
- NAS and cold storage arrays. In a mirrored or parity array (mdadm, ZFS raidz) where the data isn’t latency-sensitive, HDDs in a NAS chassis are still the economical choice.
- Secondary backup targets. rsync or Borg backups to a drive that spins up occasionally don’t need SSD speed.
What I wouldn’t do is put your root filesystem, home directory, or any VM images on a mechanical drive if you have any alternative. The cost difference on a single 500GB-1TB drive, the size most people actually need for an OS drive, is small enough that it’s not worth the daily friction. If you’re shopping, a 1TB SATA SSD is the baseline sane choice for an OS drive on an older machine, and if your motherboard has an M.2 slot, an 1TB NVMe SSD isn’t much more expensive and is noticeably faster for compiling and VM work.
How They Actually Fail
Worth knowing before you decide, because the failure patterns are different and affect how you back things up.
HDDs fail mechanically. Bearings wear, read heads degrade, platters develop bad sectors. Failure is often gradual: you’ll see rising numbers in smartctl -a for reallocated sectors or pending sectors before total failure. That gives you some warning if you’re actually checking SMART data, which most people aren’t. Sudden total failure happens too, especially from drops or power surges, since there are moving parts.
SSDs fail electrically and from write wear. NAND cells have a finite number of program/erase cycles, tracked via wear leveling. Consumer SSDs are rated for hundreds of terabytes written (TBW), and ordinary desktop use won’t get near that limit for years. The scarier failure mode is controller failure, which can happen abruptly with no warning and often takes all your data with it, unlike a dying HDD that might still let you recover sectors. Check smartctl for SSDs too, specifically “percentage used” and uncorrectable error counts.
Neither drive type is a backup strategy. Both fail. The practical takeaway is the same regardless of which you choose: keep actual backups, not RAID, not snapshots alone, an actual copy on separate hardware.
What to Actually Buy
For a Linux desktop or laptop in 2024, there’s no real debate: SSD for the OS and working files, full stop. The only open question is SATA vs NVMe, and that comes down to your motherboard’s M.2 support and budget, not whether SSDs are worth it. If you need multiple terabytes of storage and budget is tight, the right move is often a smaller SSD (250-500GB) for the system plus a 4TB internal hard drive for bulk storage, mounted separately and referenced in fstab. That split gives you SSD responsiveness where it matters and HDD economics where capacity matters more than speed.
