Hard disk drive

Pulsed Media has been running hard disk drives in production seedbox servers since 2009. Thousands of drives, two datacenters, every major manufacturer. What follows is what we learned from that -- not textbook theory, but operational reality.

The short version: HDDs are the only cost-effective way to store tens of terabytes of torrent data. An 18TB enterprise HDD costs roughly the same as a 2TB NVMe SSD. For seedbox workloads -- large sequential BitTorrent pieces, hundreds of torrents seeding at once -- raw capacity wins over raw speed.

The ST3000DM000

The Seagate ST3000DM000 (nicknamed the "D000M" by people who dealt with enough of them) deserves its own section. No other single drive model has done more damage to the hosting industry.

PM saw a 48% annualized failure rate on these drives. Nearly half of them died within a year. Backblaze published similar numbers from their own fleet (see their quarterly drive statistics, some of the best public failure-rate data anywhere).

For PM, this was close to an existential problem. At the time, PM ran RAID5 backend storage on stacked mITX motherboards with network-attached storage over iSCSI. The architecture actually performed well -- iSCSI caching made metadata operations fast, and the early mdadm RAID5 implementation was solid for the workload. But when the ST3000DM000 drives started failing at that rate, arrays were degrading faster than replacements could arrive. A 48% annual failure rate across a fleet of RAID5 arrays means you are always rebuilding somewhere, and rebuilding on failing drives means double failures, and double failures on RAID5 means data loss.

The ST3000DM000 drove home an uncomfortable truth: manufacturer reputation tells you nothing about a specific model. Seagate makes excellent drives and terrible drives. Western Digital makes excellent drives and terrible drives. The only way to know which is which is fleet-scale data over years, which is why Backblaze's public quarterly reporting matters.

Drive failure in practice

HDDs fail. The question is how they fail and what you can do about it.

SMART monitoring

Every modern HDD reports health data through SMART (Self-Monitoring, Analysis and Reporting Technology). Check it with:

smartctl -a /dev/sdX

The useful SMART attributes for predicting failure:

Attribute	What it means	When to worry
Reallocated Sector Count	Drive found bad sectors and moved data to spare sectors	Any non-zero value means the drive surface is degrading. A climbing count means replacement is coming.
Current Pending Sector Count	Sectors the drive suspects are bad but hasn't confirmed yet	These may clear on the next write (soft fail) or get reallocated (hard fail). See below.
Offline Uncorrectable	Bad sectors confirmed during offline self-test	Non-zero means the drive has sectors it cannot read anymore.
UDMA CRC Error Count	Data transfer errors between drive and controller	Usually a cable or backplane issue, not the drive itself.

Soft fails vs hard fails

Not every bad sector means the drive is dying.

Soft fails happen when a sector read returns marginal data. The drive marks it as pending. On the next write to that sector, the drive re-magnetizes the surface. If the rewrite succeeds, the pending count drops back down. The sector was temporarily unreliable -- stray magnetic field, thermal fluctuation, cosmic ray -- but the physical medium is fine. Running badblocks -wsv (destructive write test) on an unmounted partition forces every sector to rewrite, clearing soft fails.

Hard fails happen when the physical medium is actually damaged. The sector cannot hold data reliably no matter how many times you rewrite it. The drive reallocates it to a spare area on the platter. The Reallocated Sector Count goes up permanently. Once a drive starts accumulating hard reallocation events, the failure is progressive -- the drive surface is physically degrading.

The practical difference: a drive with 50 pending sectors that all clear after a rewrite pass is probably fine. A drive with 50 reallocated sectors and the count climbing weekly needs replacement.

FPDMA connectivity issues

FPDMA (First-party DMA) errors show up in dmesg as:

ata3.00: failed command: WRITE FPDMA QUEUED
ata3.00: status: { DRDY ERR }

These are often not drive failures at all. FPDMA errors frequently point to:

A bad SATA cable or loose connection
A failing backplane or drive bay connector
A SAS expander issue in a large enclosure
Power supply problems causing voltage drops during writes

Before condemning a drive for FPDMA errors: swap the cable first. Move the drive to a different bay. PM has seen FPDMA "drive failures" that were actually a single bad backplane connector affecting whatever drive happened to be in that slot.

SAS vs SATA

The enterprise storage industry sells SAS drives as premium products with premium pricing. The reality from running both types at scale:

Longevity is the same. In PM's experience -- and matching Backblaze's published data across hundreds of thousands of drives -- there is no meaningful difference in lifespan between SATA and SAS drives of similar capacity. A SATA drive rated for 24/7 NAS use lasts about as long as a SAS drive rated for 24/7 enterprise use.

SATA is often faster. Enterprise SAS drives ship with write caches disabled by default. This makes sense if you have a battery-backed RAID controller with its own cache, but in a software RAID environment like PMSS, the drive's own write cache matters. Enable it with smartctl -s wcache,on /dev/sdX and writes get noticeably faster. SATA drives ship with write cache on by default, so they tend to be faster out of the box in software RAID setups.

SAS drives cost more to run. They need SAS controllers or HBAs (a SATA drive works on both SAS and SATA controllers, but not the reverse). The smartctl output format differs between SAS and SATA: attribute names change, units change, and you need -d scsi or -d sat flags. Every monitoring and management script needs to handle both paths.

When SAS actually matters: dual-port for redundant controllers, vibration sensors in dense 20+ drive enclosures, and time-limited error recovery (TLER) for hardware RAID. A consumer SATA drive that hangs for 60 seconds during error recovery can get kicked from a hardware RAID array entirely. For software RAID with individually managed drives, these advantages are marginal.

PM uses enterprise SAS drives mainly because the secondary market is full of them. Datacenter operators replace drives on fixed schedules regardless of remaining life, so the used market has drives with years of service left at a fraction of retail. The SAS tax (controllers, extra script logic, management overhead) is worth it at those prices. But the drives themselves are not inherently better than equivalent SATA models.

Recording techniques

How a drive records data to the platter affects its performance. This matters for seedbox workloads.

CMR (Conventional Magnetic Recording)

Also called PMR (Perpendicular Magnetic Recording). Tracks are written side by side without overlap. Each track can be rewritten independently. This is the standard recording method and the only one suitable for seedbox hosting.

Only non-shingled, 7200 RPM, high-performance CMR variants work for seedbox servers. BitTorrent writes are continuous -- hundreds of torrents writing small pieces concurrently across the entire disk surface. That requires random write performance that only CMR drives deliver consistently.

SMR (Shingled Magnetic Recording)

SMR drives overlap tracks like roof shingles to increase density. Reading works normally, but writing to a track in the middle of a shingled region requires rewriting all overlapping tracks. The drive manages this internally with a write cache and background reorganization.

Early SMR drives (around 2015-2017) were not as bad as their reputation. They handled sustained sequential writes reasonably well, and the managed shingling zones were large enough that typical workloads rarely triggered the worst-case rewrite cascades.

Later models got worse. As manufacturers pushed SMR to higher capacities and tighter zone densities, the performance cliff during sustained random writes became more severe. A modern SMR drive under heavy random write load can slow to a fraction of its rated speed while the drive internally shuffles shingled zones.

The Seagate CMR-to-SMR swap

In 2020, Seagate shipped drives marketed as suitable for NAS and RAID use that turned out to be SMR. The model numbers were nearly identical -- the difference between a CMR drive and its SMR replacement was as small as ST3000DM000 vs ST3000DM0001 (one extra digit). No disclosure on product pages or datasheets until the community caught it.

Western Digital had similar issues with certain Red NAS drives.

For operators: always verify the recording technology before purchasing drives in quantity. Check the manufacturer's product specification PDF, not just the product page. If the spec sheet does not explicitly state "CMR" or "PMR": assume SMR until proven otherwise.

Rotational speed

HDD platters spin at fixed RPM. Higher RPM means lower rotational latency (less time waiting for the right sector to spin under the head) and higher sustained throughput.

RPM	Avg rotational latency	Typical use
5,400	5.6 ms	Consumer desktop, external drives, archival
7,200	4.2 ms	Standard server and NAS drives, seedbox storage
10,000	3.0 ms	Legacy enterprise (largely replaced by SSDs)
15,000	2.0 ms	Dead. Nobody ships new 15K drives anymore.

Seedbox servers use 7,200 RPM exclusively. 5,400 RPM cannot handle concurrent multi-user workloads. The 10K and 15K RPM enterprise drives traded capacity for speed, topping out at 900 GB and 600 GB respectively. SSDs own that performance tier now.

How an HDD works

An HDD contains one or more circular platters coated in magnetic material, stacked on a spindle motor. A set of read/write heads -- one per platter surface -- float nanometers above the spinning platters on an actuator arm.

To read data, the actuator moves the head to the correct track (seek time), then waits for the right sector to spin under the head (rotational latency). Combined, random access takes roughly 10ms per operation on a 7,200 RPM drive. This is why HDDs are slow at random I/O compared to SSDs, but fast at sequential reads and writes where the head stays in position while data streams past.

Modern helium-filled drives reduce internal turbulence, allowing more platters in the same form factor. This is how 18-24 TB drives are possible -- more platters, tighter tolerances, sealed helium environment.

HDDs at Pulsed Media

PM uses enterprise HDDs in RAID arrays across all seedbox tiers:

V series (V1000, V10G): RAID 0 -- maximum usable capacity and throughput, no redundancy. If a drive fails, data on that array is lost.
M series (M1000, M10G): RAID 5 -- one drive can fail without data loss. One disk's worth of capacity goes to parity.

Seedbox workloads are mostly sequential: BitTorrent writes large pieces (typically 1-4 MB) to disk, and users download complete files via SFTP or HTTP. This plays to HDD strengths. The random I/O where SSDs dominate is less relevant -- though PM uses NVMe as a swap/cache tier on newer servers for the random I/O that does occur.

When a drive fails in a RAID array, the array continues in degraded mode. The failed drive gets replaced and the array rebuilds. During rebuild, performance drops hard -- PM has measured approximately 8.9x slower writes and 8.2x slower reads during RAID5 resync on production hardware. See RAID for details on rebuild behavior.

HDD vs SSD

SSDs are faster than HDDs at random I/O by a factor of 100x or more. But the idea that SSDs are inherently more reliable deserves some context.

Early enterprise SSDs (roughly 2012-2015) had failure rates that made the ST3000DM000 look respectable. At PM, SSD failures during that era were so common that some staff would just assume any server issue was another dead SSD, without testing first. The controller firmware was immature: wear leveling barely worked, garbage collection could not keep up with write amplification, and the flash translation layer would corrupt under sustained production load.

They also degraded before dying. A new SSD would benchmark at rated speed, but after months of real use, write speeds cratered. The controller could not keep up with garbage collection and the overprovisioned space ran out. This was not NAND wear (the cells still had endurance left). It was firmware.

Modern SSDs (2020+) have solved most of these issues. But the history matters because the "SSDs are reliable, HDDs are not" narrative comes from a period when SSDs were new and exciting and HDDs were old and boring. In practice, both fail. HDDs fail mechanically: bearings, heads, motors. SSDs fail electronically: controller bugs, NAND wear, capacitor failures. RAID protects against both.

For bulk seedbox storage, HDDs still win on cost per terabyte by 4-5x. PM uses NVMe as a swap and cache tier for hot data, and HDDs for bulk storage. This combination gives SSD-like responsiveness for cached data while keeping multi-terabyte storage affordable.

Backblaze drive statistics

Backblaze publishes quarterly drive failure statistics from their fleet of over 250,000 drives. It is some of the best publicly available reliability data in the industry, and PM's own fleet observations match theirs closely: no meaningful longevity difference between consumer and enterprise drive classes, and specific models (not brands) that fail at disproportionate rates.

If you are evaluating drives for a build, read Backblaze's quarterly reports before committing to a manufacturer or model.