CONCEPT Cited by 2 sources

Hard-drive physics (capacity vs. seek-time)

Definition

Hard drives are mechanical devices (spinning platters + moving arm + flying head). This constrains them in a way that grows more severe every generation: capacity scales fast, seek time does not.

The numbers (Warfield, 2025)

Compared to the first commercially available hard drive — IBM's 1956 RAMAC 350 — today's largest HDD (2023, WD Ultrastar DC HC670, 26 TB):

Dimension	Improvement
Capacity	7,200,000×
Physical size (volume)	1/5,000×
Cost per byte (inflation-adjusted)	1/6,000,000,000×
Seek time (random access)	150×

The seek-time number is the problem. It's grown linearly while capacity has grown exponentially, because it's gated by physical mechanics: you must wait for the arm to move and the platter to spin.

The constant behind every S3 placement decision

If you are doing random reads and writes to a drive as fast as you possibly can, you can expect about 120 operations per second. The number was about the same in 2006 when S3 launched, and it was about the same even a decade before that.

A drive's random-access IOPS budget has been roughly constant for 30 years. Capacity keeps scaling. Therefore:

• IOPS per byte keeps falling. This is the hard constraint on services that store large fractions of their data on HDDs.
• Industry roadmaps point to 200 TB/drive this decade. At that point a drive has 1 I/O per second per 2 TB — roughly a single I/O per second for a small company's entire first-year-of-data. S3 plans to use these drives anyway.

Why HDDs still exist

Flash dominates consumer devices and much of enterprise storage. Jim Gray's 2006 line: "Tape is Dead. Disk is Tape. Flash is Disk. RAM Locality is King." Still, HDDs remain the only cost-efficient medium for bulk capacity-dominant, read-predominantly-cold storage at S3's scale.

The 747-over-grass analogy (2023 edition)

Warfield updates a classic HDD scale analogy:

Imagine a hard drive head as a 747 flying over a grassy field at 75 miles per hour. The air gap between the bottom of the plane and the top of the grass is two sheets of paper. Now, if we measure bits on the disk as blades of grass, the track width would be 4.6 blades of grass wide and the bit length would be one blade of grass. As the plane flew over the grass it would count blades of grass and only miss one blade for every 25 thousand times the plane circled the Earth.

That 1-miss-per-25,000-Earth-orbits figure is the HDD bit error rate of 1 in 10¹⁵ reads. At S3 scale, that "rare" error happens regularly and must be engineered against.

Architectural implications

• Bigger drives are almost always a net win for the store (capacity dominates), but each step change tightens the IOPS-per-TB screws another notch.
• Random I/O is the adversarial workload. Placement needs to turn random into more-sequential where possible, and to balance what's left.
• You cannot test against a real drive at 120 IOPS. That's the argument for executable specifications like ShardStore's (see systems/shardstore).
• Redundancy schemes pull double duty. Replicas / erasure-coded shards are both durability mechanisms and I/O-steering mechanisms, because you can read from any non-hot copy.

Seen in

• sources/2025-02-25-allthingsdistributed-building-and-operating-s3 — Warfield's FAST '23 numbers and analogy; the physics framing for S3's heat-management story.
• sources/2025-08-08-dropbox-seventh-generation-server-hardware — Dropbox 7th-gen hardware post surfaces a second structural constraint the Warfield framing doesn't cover: at 30+ TB drive capacities with 11 platters (SMR Ultrastar HC690), the read/write head's nanometer precision leaves vanishing margin against the vibration of 10k-RPM fans packed into a denser chassis. Vibration → position error signal (PES) events; worst case a write fault forces the drive to retry. And drives age fastest above ~40 °C, so you can't just slow the fans. The Sonic chassis is co-designed to trade acoustic damping, airflow redirection, and fan-curve tuning against this axis. Adds a mechanical envelope constraint on top of the IOPS-per-capacity constraint Warfield defined.

Two structural constraints combined

The two sources together define the full physics envelope HDDs operate under at hyperscale:

Source	Constraint	Scales how
Warfield / S3 (2025)	IOPS per drive flat (~120 IOPS since 2006)	Capacity keeps scaling → IOPS/TB falls
Dropbox / Sonic (2025)	Vibration tolerance tightens with platter count	11-platter 30 TB drive has nanometer-level head tolerance against 10k-RPM fan vibration

The operational implications compound:

• You can't just add drives — IOPS/TB is the Warfield constraint.
• You can't just add cooling — fan RPM is the Dropbox constraint.
• You can't just build denser chassis — both constraints tighten simultaneously.

Hence the co-development arc: drive firmware + chassis design + fan curves + airflow geometry must evolve together across hardware generations (see concepts/hardware-software-codesign and patterns/supplier-codevelopment).