HDD: Explanation & Insights

Spinning platters, magnetic heads, and fifty years of storing everything humanity has ever recorded.

What It Is

HDD stands for Hard Disk Drive, and the name is literal: one or more rigid metal platters coated in a thin magnetic film, spinning at thousands of revolutions per minute inside a sealed enclosure, while a set of read/write heads float just nanometers above the surface on a cushion of air. If the platter were the size of a football field, the head would be a 747 cruising at full speed, three millimeters off the ground. That's not a metaphor for dramatic effect — it's the actual scale, and the fact that this works at all, billions of times a second, for years on end, is one of the great engineering achievements of the twentieth century.

The principle is straightforward: magnetize a tiny region of the platter in one direction for a 1, the other direction for a 0. The platter spins, the head moves to the right track, and data flows. Reading is the reverse: the head senses the magnetic orientation as the platter sweeps past and converts it back to bits. Every file you've ever saved, every database row, every log entry — at the physical layer, it's a pattern of magnetic north and south on a spinning disk.

HDDs have dominated storage for over half a century. SSDs are faster and now cheaper per gigabyte at small capacities, but HDDs still store the overwhelming majority of the world's data — every cloud backup, every surveillance archive, every data warehouse that measures capacity in petabytes. The reason is simple economics: at scale, magnetic platters remain the cheapest way to store a bit. Understanding HDDs isn't nostalgia. It's knowing what's actually holding your data when the RAID array label says "20 TB."

Why It Matters

Every server admin needs to understand HDDs for one reason: they are mechanical devices, and mechanical devices wear out. An SSD has no moving parts and fails when its flash cells exhaust their write cycles. An HDD has a motor, a spindle, bearings, and an actuator arm that sweeps back and forth thousands of times per second. Each of those parts degrades with use, heat, and vibration. The bearings wear. The heads drift. The lubricant on the platters thins. And eventually — always eventually — something gives.

The good news is that HDDs are unusually honest about their decline. The SMART system (Self-Monitoring, Analysis, and Reporting Technology) built into every modern drive tracks dozens of health metrics — reallocated sectors, spin-up retries, seek errors, temperature — and the trend lines tell you when a drive is headed for failure, often weeks or months before it dies. This is the central argument for monitoring your HDDs: they don't just fail silently. They complain first, in a language smartctl speaks fluently. If you're listening, you get to replace the drive on your schedule. If you're not, the drive picks the schedule — and it's always 3 a.m. on a holiday weekend.

Backblaze, the cloud backup company, publishes quarterly failure statistics on the quarter-million drives in their data center. The numbers are real, the sample sizes are enormous, and the data consistently shows annualized failure rates (AFR) between 0.5% and 5%, depending on the model and age. Young drives (under one year) sometimes fail early due to manufacturing defects — the "infant mortality" phase. Drives that survive the first year tend to be stable for three to five years. After five years, the failure curve starts climbing again. At ten years, you're running on borrowed time. These numbers should shape your replacement and RAID strategy: if you have twenty drives past year five, statistically one of them is about to go.

The Physics Inside

Understanding what's physically happening inside an HDD clarifies everything about its performance characteristics and failure modes. There are four key components.

Platters. Aluminum or glass discs, polished to a mirror finish, coated with a cobalt alloy magnetic film just 15–20 nanometers thick. A single drive may have one to five platters stacked on a shared spindle, with data written on both sides of each platter. More platters mean more capacity in the same form factor, but also more complexity, more heat, and more mass for the motor to spin.

Spindle motor. A brushless DC motor that rotates the platters at a constant speed. Common speeds are:

RPM	Typical Use	Latency per Revolution
5,400	Desktop, NAS, cold storage	11.1 ms
7,200	General-purpose server, workstation	8.3 ms
10,000	Enterprise (legacy), database volumes	6.0 ms
15,000	Enterprise (legacy), high-IOPS workloads	4.0 ms

The 10k and 15k drives are nearly extinct — SSDs and NVMe drives beat them on every metric for less money. Modern HDD purchases are almost exclusively 5,400 or 7,200 RPM.

Actuator arm and heads. A voice-coil motor swings the arm across the platter surface, positioning the read/write heads over the correct track. This is the seek — the mechanical movement that determines how fast the drive can jump between unrelated data. A typical seek takes 4–12 milliseconds, which sounds fast until you compare it to the microseconds an SSD needs for the same operation. Seek time is the HDD's Achilles' heel, and understanding it is the single most important insight on this page.

Controller board. The PCB on the underside of the drive handles the interface protocol (SATA, SAS), manages the cache (usually 64–256 MB of DRAM), translates logical block addresses to physical locations, and runs the SMART firmware. It's also where error correction happens — the magnetic signal is noisy, and the controller applies ECC algorithms to every sector read to keep the bit error rate below one in 10^15.

Sequential vs Random: The Key Insight

This is the single most important thing to understand about HDDs, and it explains almost every performance decision a server admin will ever make about storage.

Sequential access is fast. When you read a large file — a log archive, a backup tarball, a video — the head parks on the starting track and the data streams past as the platter spins. A modern 7,200 RPM drive can sustain 150–200 MB/s reading sequentially. That's respectable even by modern standards. Restoring a 500 GB backup takes under an hour. Streaming video to a dozen clients works fine. For bulk throughput, HDDs are serviceable even today.

Random access is agonizingly slow. When your workload asks for block A, then block Z, then block M — each from a different part of the platter — the head must physically move between tracks for every request. Each seek costs 4–12 ms of mechanical travel, plus half a revolution of rotational latency waiting for the right sector to come around (4.2 ms at 7,200 RPM). Call it 8–15 ms per random read. That gives you roughly 75–125 random IOPS (I/O operations per second) from a single HDD.

For comparison, a SATA SSD delivers 20,000–100,000 random IOPS. An NVMe drive delivers 200,000–1,000,000+. The gap is not 2× or 10×. It's three to four orders of magnitude.

This is why running a database on an HDD is painful. A busy MySQL or PostgreSQL instance doing index lookups, joining across tables, and writing transaction logs is fundamentally a random I/O workload. Each query might touch dozens of unrelated pages scattered across the disk. At 100 IOPS, that's a handful of queries per second before the drive becomes the bottleneck. The same workload on an NVMe drive runs a thousand times faster — not because the data is different, but because the storage device doesn't have to move a physical arm to reach it.

Pro Tip

If your server feels sluggish and top shows high iowait, check whether the busy disk is an HDD handling random I/O. Moving the database or frequently-accessed files to an SSD often transforms a struggling server into a responsive one — it's the highest-leverage hardware change you can make.

Best practice: Use HDDs for sequential, bulk workloads — backups, archives, media storage, log retention. Use SSDs or NVMe for anything latency-sensitive — operating systems, databases, application data, swap. If your server has both, this split should be the first thing you configure.

Form Factors

Two sizes dominate:

3.5-inch is the standard HDD form factor for servers and desktops. It allows room for more platters, which means higher capacities — current models reach 20–24 TB in a single drive. Server chassis with 3.5" bays are built for these. If you're buying HDDs for a NAS, a RAID array, or bulk storage, you're buying 3.5" drives.

2.5-inch was once common for laptop HDDs, but the form factor has been almost entirely taken over by SSDs. You can still buy 2.5" HDDs (typically 500 GB to 2 TB), but there's rarely a reason to — an SSD in the same bay is faster, more durable, and increasingly cheaper at those capacities. The 2.5" HDD is essentially a transitional technology that's been transitioned away from.

Enterprise drives add SAS (Serial Attached SCSI) as an alternative to SATA. SAS supports dual-port connections (two paths to the same drive for failover), full-duplex communication, and longer cables. If your server has a SAS backplane, it will accept both SAS and SATA drives — but a SATA port won't accept a SAS drive. In practice, most Linux servers you'll encounter use SATA drives. SAS is mainly found in enterprise storage arrays and high-end database servers.

CMR vs SMR: A Gotcha Worth Knowing

Traditional HDDs use CMR (Conventional Magnetic Recording): tracks are written side by side with a guard band between them, and any track can be rewritten independently without disturbing its neighbors. This is the recording method that has worked since the 1950s, and it behaves exactly the way you'd expect — write anywhere, anytime, no surprises.

SMR (Shingled Magnetic Recording) squeezes more tracks onto the platter by overlapping them like roof shingles. The write head is wider than the read head, so writing a track partially overwrites the adjacent track. This means you can't rewrite a single track without rewriting several neighbors — the drive must read the affected tracks into cache, modify the target, and rewrite the whole band. For sequential writes (backup, archival, surveillance footage), this is fine — the drive writes in order and the overlap doesn't matter. For random writes (databases, virtual machines, anything with scattered small updates), SMR is dramatically slower, because every small write triggers a read-modify-write cycle on a whole band of tracks.

The controversy: in 2020, Western Digital was caught shipping SMR drives under the WD Red label — a product line marketed specifically for NAS and RAID use, exactly the workloads where SMR performs worst. The drives would work fine during initial setup, then slow to a crawl under real NAS workloads, and RAID rebuilds could take days instead of hours. Seagate and Toshiba had similar labeling issues. The fallout led to clearer labeling industry-wide, but the lesson remains:

Best practice: For any server or NAS use, verify that the drive is CMR, not SMR. Check the manufacturer's datasheet — the word "CMR" or "Conventional" should appear. If the spec sheet doesn't mention the recording method, treat that as a warning sign. SMR drives are fine for cold archive and sequential backup to a single large file, but they have no place in a RAID array or under a database.

How HDDs Fail

HDDs are more predictable in their failure than most hardware, and that predictability is their saving grace. The most common failure modes:

Bad sectors (gradual). Individual sectors become unreadable as the magnetic coating degrades. The drive's firmware detects this and remaps the data to a spare sector from a reserved pool — this is the "reallocated sector count" in SMART data. A few reallocated sectors over years of service is normal. A count that's climbing week over week is a drive that's dying. The data is still safe (the firmware moved it), but the spare pool is finite, and when it runs out, the next bad sector means data loss.

Mechanical failure (sudden). The spindle motor seizes, the actuator arm sticks, a head crashes into the platter. These are the failures that come with no warning — the drive is fine and then it's not. They're less common than gradual degradation, but they do happen, especially with age, heat, and vibration. RAID exists specifically for this scenario.

Firmware bugs. The controller's firmware occasionally has bugs that can cause data corruption or drive lockups. These are rare but real — specific firmware versions of specific models sometimes develop known issues, and manufacturers release firmware updates. Check the manufacturer's support page if you're seeing unexplained errors on a specific model.

Environmental. Excessive heat accelerates every failure mode. Excessive vibration — from fans, from adjacent drives, from a poorly mounted chassis — causes the heads to mistrackline, increasing seek errors. Google's famous 2007 study found that drives running above 40°C had significantly higher failure rates. Keep your drives cool, keep your chassis vibration-dampened, and let SMART temperature monitoring confirm it.

How I Inspect It

Three commands form the toolkit for understanding what HDDs are in a server, how they're configured, and whether they're healthy.

lsblk — What's Installed

lsblk lists every block device the kernel knows about. It's your first stop:

lsblk -o NAME,SIZE,TYPE,ROTA,MODEL,SERIAL,MOUNTPOINT

NAME    SIZE TYPE ROTA MODEL            SERIAL           MOUNTPOINT
sda     3.6T disk    1 ST4000NM000A     ZPT12345         
├─sda1    1G part    1                                   /boot
├─sda2   50G part    1                                   /
└─sda3  3.6T part    1                                   /data
sdb     3.6T disk    1 ST4000NM000A     ZPT12346         
├─sdb1    1G part    1                                   
├─sdb2   50G part    1                                   
└─sdb3  3.6T part    1                                   
nvme0n1 477G disk    0 Samsung 970 EVO  S4EWNX0N123456   
└─nvme0n1p1 477G part 0                                 /fast

The ROTA column is the one that matters here: 1 means rotational (HDD), 0 means non-rotational (SSD/NVMe). This is how the kernel tells you which drives are spinning platters and which are flash. The SERIAL column is critical when you need to identify a physical drive for replacement — device names like /dev/sda can shift between reboots, but serials are permanent.

smartctl — Is It Healthy?

smartctl reads the SMART data from a drive's firmware. The essential check:

smartctl -a /dev/sda

The output is long, but for HDDs you care about a handful of attributes:

Attribute	What It Means	Worry When...
Reallocated Sector Count	Bad sectors remapped to spares	Count is rising
Current Pending Sector Count	Sectors awaiting remap (unreadable)	Any value > 0
Offline Uncorrectable	Sectors that failed offline verification	Any value > 0
Spin Retry Count	Failed attempts to spin up the motor	Any value > 0
Seek Error Rate	Head positioning failures	Trend is rising
Temperature	Drive operating temperature in °C	Sustained above 45°C
Power-On Hours	Total hours the drive has been running	Above 40,000 (≈4.5 years 24/7)

A drive with zero reallocated sectors, zero pending sectors, and a temperature under 40°C is a happy drive. A drive with a climbing reallocated sector count is a drive you should replace — not today, not in a panic, but soon, before it runs out of spare sectors and starts losing data. This is the window that SMART monitoring gives you, and it's the entire reason CleverUptime watches these numbers.

hdparm — Performance and Configuration

hdparm shows and controls drive-level settings. The most useful invocation for an HDD:

hdparm -I /dev/sda

This prints the drive's identity: model, firmware version, serial, supported features (NCQ, APM, write cache), and the interface speed. For a quick sequential benchmark:

hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 564 MB in  3.00 seconds = 187.88 MB/sec

That 188 MB/s is the sequential read throughput — the best-case scenario, reading contiguous data from the outer tracks. Real-world performance with mixed workloads will be lower. But this number is useful for verifying that a drive is performing at spec — a 7,200 RPM drive reading below 100 MB/s might have a hardware issue.

Warning

Never disable write cache on an HDD without understanding the trade-off. Write cache (hdparm -W1) lets the drive acknowledge writes before they're committed to the platter, which dramatically improves write performance. Disabling it (hdparm -W0) means every write waits for physical confirmation — safer against power loss, but potentially 10× slower for random writes. If your server has a UPS, leave write cache on. If it doesn't, that's the bigger problem to solve.

Cheat Sheet

# --- Identify drives ---
lsblk -o NAME,SIZE,TYPE,ROTA,MODEL,SERIAL     # ROTA=1 → HDD, ROTA=0 → SSD/NVMe
cat /sys/block/sda/queue/rotational            # 1 = HDD, 0 = SSD (per device)

# --- Health check ---
smartctl -H /dev/sda                           # quick pass/fail health status
smartctl -a /dev/sda                           # full SMART data and attributes
smartctl -l error /dev/sda                     # error log (recent I/O failures)
smartctl -t short /dev/sda                     # start a short self-test (~2 min)
smartctl -t long /dev/sda                      # start a long self-test (~hours)
smartctl -l selftest /dev/sda                  # results of completed self-tests

# --- Performance ---
hdparm -t /dev/sda                             # sequential read benchmark
hdparm -I /dev/sda                             # drive identity and feature flags
iostat -x 1 5                                  # per-device I/O stats (if available)

# --- Temperature ---
smartctl -a /dev/sda | grep -i temp            # current temperature from SMART
hddtemp /dev/sda                               # dedicated temp tool (if installed)

# --- Disk usage (filesystem level) ---
df -h                                          # free space on mounted filesystems

Gotchas

Real traps, in order of how often they catch people:

Putting a database on an HDD. This is the most common performance mistake on a budget server. A database is a random I/O workload, and an HDD delivers 100 IOPS. The math doesn't work. If you can afford exactly one SSD, put the database on it and leave everything else on the HDD. That single change will matter more than doubling your RAM.
Ignoring SMART warnings. A reallocated sector count that was 0 last month and is 8 this month is a drive asking to be replaced. The sectors that have been remapped are fine — the firmware handled them. But the trend means the platter surface is degrading, and the spare pool is finite. Replace the drive during the warning phase, not the failure phase.
Buying SMR drives for a NAS or RAID. CMR and SMR drives look identical on spec sheets. SMR drives are often cheaper, which is exactly how they end up in a RAID array where they'll take days to rebuild instead of hours. Always check the recording method before buying. CMR for servers, no exceptions.
Running drives too hot. Every 10°C above 30°C roughly doubles the chemical degradation rate of the magnetic coating. A drive at 55°C in a poorly ventilated chassis is aging at four times the rate of one at 35°C with proper airflow. Monitor temperature via SMART, and if drives are consistently above 45°C, fix the airflow before anything else.
Trusting device names across reboots. /dev/sda today might be /dev/sdb tomorrow if you added a drive, or if the BIOS enumeration order changed, or for no apparent reason at all. Use UUIDs in /etc/fstab and identify physical drives by serial number (from lsblk or smartctl), not by /dev/sdX paths.
No RAID on HDDs. A single HDD is a single point of failure, and HDDs fail more often than SSDs. If the data matters, put at least a RAID 1 mirror under it. The cost of one extra drive is trivial compared to the cost of restoring from backup — or discovering you don't have one.

History and Philosophy

The first hard disk drive was the IBM 350, shipped in 1956 as part of the RAMAC 305 system. It held 5 megabytes on fifty 24-inch platters and weighed over a ton. You could lease it for $3,200 a month — about $35,000 in today's money — for the privilege of storing roughly one MP3 song. The thing occupied an entire room and required its own air conditioning.

Nearly seventy years later, a 20 TB drive fits in your palm and costs $300. That's a storage density improvement of roughly four trillion times, which makes Moore's Law look modest by comparison. The progression — from room-sized cabinets to sealed 3.5" enclosures to the 2.5" drives in laptops — is a story of relentless miniaturization: smaller platters, finer magnetic grains, heads flying closer to the surface, track pitches measured in tens of nanometers.

The industry has been through several recording revolutions. Longitudinal recording (magnetic domains parallel to the platter surface) gave way to perpendicular recording around 2005, which stood the domains on end and roughly tripled the achievable density. SMR pushed further by overlapping tracks, trading write flexibility for density. The next frontier is HAMR (Heat-Assisted Magnetic Recording), where a laser momentarily heats a tiny spot on the platter to make the magnetic grains easier to flip, enabling even smaller bit cells. Seagate has been shipping HAMR drives in limited quantities since 2023, targeting 30+ TB capacities.

The philosophical tension in storage today is HDDs vs SSDs, and it's not really a contest on performance — SSDs win by orders of magnitude. The question is economics. Flash memory prices have been dropping roughly 30% per year, and for capacities under 4 TB, SSDs are now cheaper per gigabyte than HDDs. But HDDs still dominate above 4 TB, and the crossover point keeps moving but hasn't arrived for bulk storage. The world generates data faster than flash fabs can build capacity, and until that changes, the spinning platter isn't going anywhere. It's just moving from "the storage" to "the archive" — from the hot tier where speed matters to the cold tier where cost per bit is everything.

For a server admin, the practical consequence is clear: your server probably has both, or should. SSD or NVMe for the fast path, HDDs for the deep storage. Understand the strengths and limits of each, monitor both via SMART, put RAID under everything, and you'll sleep well.