Disk Structure and Geometry

A hard disk drive stores data on one or more rigid circular platters, each coated with a magnetizable film and spinning on a common spindle at a constant angular velocity, typically 5,400 to 15,000 revolutions per minute (RPM). Data on each platter surface is arranged into concentric rings called tracks. Each track is subdivided into fixed-size arcs called sectors, historically 512 bytes and now commonly 4,096 bytes (the "4Kn" or Advanced Format standard). A cylinder is the set of tracks at the same radial distance across all platter surfaces — moving the read/write head assembly to a given radius accesses one cylinder's worth of tracks simultaneously, one per surface, without further arm movement. The read/write heads are mounted on a single actuator arm assembly, so all heads move together in lockstep; you cannot position the head on platter 1 independently from the head on platter 2. This mechanical coupling is precisely why the cylinder — not the track — is the natural unit of "free" locality: once the arm has paid the cost of a seek to reach a cylinder, the OS can read any track within that cylinder (by switching to a different head electronically) at negligible extra cost, and it can read many sectors around that cylinder as the platters rotate beneath the heads. The operating system and application software never manipulate cylinder/head/sector (CHS) triples directly in modern systems. Instead, the storage stack addresses the disk through Logical Block Addressing (LBA): the entire drive's sectors are numbered sequentially from `0` to `N−1`, and the drive's own firmware (the disk controller) performs the LBA-to-physical translation internally, including remapping around bad sectors transparently. This indirection is a clean instance of the same abstraction principle used throughout the storage stack — the Device Driver issues LBA-based commands over an interface such as SATA or NVMe, and the physical geometry is entirely hidden below that interface. The OS's file system allocates logical blocks, but performance-aware allocation and scheduling policies still reason about the physical consequences of LBA choices, because contiguous LBAs are (usually, though not perfectly, since manufacturers may remap) contiguous in physical space.

Every disk I/O request — read or write a block at a given LBA — resolves mechanically through three sequential phases, and the total service time is their sum:

Seek time is the time for the actuator arm to move the read/write heads radially from their current cylinder to the target cylinder. It has a fixed component (acceleration/deceleration overhead) and a variable component roughly proportional to the square root of the distance moved (because the arm accelerates, then decelerates, rather than moving at constant speed), though vendors typically publish only an average seek time and a track-to-track seek time as headline numbers.

Rotational latency is the time to wait for the platter to spin until the target sector rotates under the head, once the head is on the correct cylinder. Because the target sector's position relative to the head is effectively uniformly distributed over one revolution for a random access pattern, the average rotational latency is exactly half the time for one full revolution:

Transfer time is the time to actually move the requested bytes across the head-to-controller-to-bus path once the sector is under the head; it depends on the sector size, the number of sectors requested, and the drive's sustained transfer rate. ``` function disk_access_time(request, drive):

# request: target LBA and length; drive: geometry + timing specs current_cyl = drive.head_position_cylinder target_cyl = lba_to_cylinder(request.lba, drive.geometry)

# --- Seek phase --- distance = abs(target_cyl - current_cyl) if distance == 0: seek_time = 0 else: seek_time = drive.seek_overhead + drive.seek_per_cylinder * sqrt(distance)

# sqrt models the accelerate/decelerate motion profile;

# many textbook problems instead use the vendor's flat "average seek time"

# --- Rotational phase --- rotation_time_full = 60000.0 / drive.rpm # ms per full revolution

# Expected wait assuming target sector position is uniformly random: rotational_latency = rotation_time_full / 2.0

# --- Transfer phase --- bytes_per_track = drive.sectors_per_track drive.bytes_per_sector fraction_of_track = request.length_in_bytes / bytes_per_track transfer_time = fraction_of_track rotation_time_full total = seek_time + rotational_latency + transfer_time drive.head_position_cylinder = target_cyl # arm now parked here return total

function lba_to_cylinder(lba, geometry):

# geometry gives sectors_per_track and heads (surfaces) per cylinder sectors_per_cylinder = geometry.sectors_per_track geometry.heads cylinder = lba // sectors_per_cylinder remainder = lba % sectors_per_cylinder head = remainder // geometry.sectors_per_track sector = remainder % geometry.sectors_per_track return cylinder # (head, sector also available if physical CHS is needed) ``` The pseudocode makes explicit an important invariant: <strong>the seek cost of the next* request depends on where the arm currently sits, which is exactly the state that Disk Scheduling Algorithms manipulate by reordering the request queue to minimize cumulative arm travel. The transfer-time computation assumes data is read as a fraction of one track's worth of bytes per revolution — a simplification, but it is the standard first-order model used in every introductory treatment and it is dimensionally and physically sound: transfer rate is bytes-per-track divided by time-per-revolution.

Space: the geometric model itself requires no per-request extra storage; the drive controller maintains a fixed-size translation table (or an algorithmic mapping) from LBA to physical CHS, which is $O(1)$ additional state per drive, independent of the number of requests served.

Time per request: a single disk access, under the model above, costs

Seek time's dependence on distance $d$ (in cylinders) being $O(\sqrt{d})$ rather than $O(d)$ follows from basic kinematics: the arm accelerates for roughly the first half of the seek and decelerates for the second half, so for a constant-acceleration motion profile, distance traveled scales as (time)², giving $\text{time} \propto \sqrt{\text{distance}}$. This is why manufacturers publish both a small "track-to-track" seek time and a much larger "average seek time" (over a random distance uniformly spread across the whole disk) — the relationship is sublinear, not linear, in distance.

Why rotational latency averages exactly half a revolution — the correctness argument: model the target sector's angular offset from the head, at the moment the head arrives at the correct cylinder, as a random variable $\Theta$ uniformly distributed on $[0, 2\pi)$ (a reasonable assumption when the workload is not correlated with the disk's rotational phase, which holds for arbitrary/random access patterns). The wait time is $T = \frac{\Theta}{2\pi} \cdot T_{\text{rev}}$ where $T_{\text{rev}}$ is the time for one full revolution. Then

using $\mathbb{E}[\Theta] = \pi$ for a uniform distribution on $[0, 2\pi)$. This is not a rough rule of thumb; it is an exact consequence of the uniformity assumption, and it is the reason every textbook average-latency formula divides RPM-derived revolution time by exactly 2.

Honesty about the model's limits. This is a first-order physical model, and real drives deviate from it in several ways worth naming explicitly:

• Zoned bit recording means outer tracks hold more sectors than inner tracks (to keep areal density roughly constant), so "bytes per track" is not a single constant across the disk — sequential transfer rate is higher on outer cylinders.
• The $O(\sqrt{d})$ seek model is an idealization; real seek curves include fixed settling time and are often better approximated with a small constant term plus a square-root term, exactly as in the pseudocode above.
• Modern drive firmware performs command queuing (NCQ) and may reorder requests internally, so the OS-visible geometry is a controller-mediated approximation of the true physical layout, not a guarantee.
• LBA-contiguous blocks are usually physically contiguous, but bad-sector remapping and firmware-level wear leveling on hybrid drives can break this assumption silently.

The overall tradeoff this section sets up: because $T_{\text{seek}}$ and $T_{\text{rotation}}$ are mechanical and dominate cost, while $T_{\text{transfer}}$ is comparatively cheap and scales gently with request size, the single biggest lever the OS has for HDD performance is minimizing seek distance across a batch of pending requests — which is precisely the job of Disk Scheduling Algorithms such as SCAN and C-SCAN.

Consider a disk with the following published specifications, typical of a 7,200 RPM consumer HDD:

Step 1 — Rotation time per revolution.

Step 2 — Average rotational latency.

Step 3 — Transfer time for one sector (512 bytes). One track holds $500 \times 512 = 256{,}000$ bytes, transferred in $8.33$ ms, so:

Step 4 — Request 1: seek from cylinder 4,000 to 4,050 (distance 50). Using the average seek time figure directly (the common introductory simplification, treating any "typical" seek as costing the published average):

Step 5 — Request 2: seek from cylinder 4,050 to 4,051 (distance 1, adjacent cylinder). Here the track-to-track seek time applies instead, since the arm barely moves:

The lesson made concrete: servicing these two requests in this order (as they might arrive from independent processes) costs $13.19 + 5.19 = 18.38$ ms. But notice that request 2's tiny seek distance is only cheap because request 1 already moved the arm to a nearby cylinder. If instead the requests had arrived interleaved with a third request at cylinder 100, naive first-come-first-served order could force the arm to swing back and forth across nearly the whole disk — the exact expensive pattern that motivates Disk Scheduling Algorithms, which reorder the queue (e.g., by nearest-cylinder-first or by sweeping monotonically like an elevator) to keep consecutive seeks small, the way request 2 above was small purely by lucky ordering.

The mechanical disk drive and its geometric model emerged from IBM's storage research, transforming computing from sequential tape-based storage into random-access secondary storage — a shift as consequential to systems design as the stored-program concept was to computer architecture itself.

Every operating system's I/O scheduler — the Linux `mq-deadline`, `bfq`, and legacy `cfq` schedulers, Windows' storage stack, and the disk-arm-scheduling algorithms taught immediately after this topic — exists because of the cost structure derived here: seek and rotation dominate, transfer is cheap, so reordering requests to minimize arm travel yields real throughput gains. Database systems exploit this geometry explicitly: B-tree page layout, log-structured merge trees, and write-ahead logging are all designed to convert random I/O into sequential I/O, because sequential access amortizes the fixed seek-plus-rotation cost over far more bytes transferred. File system allocators (e.g., ext4's block groups, NTFS's cluster allocation) try to keep related blocks physically close, directly leveraging the fact that a cylinder's worth of data is nearly free once the arm has already arrived. RAID controllers stripe data across drives with full awareness of per-drive geometry to parallelize seeks across spindles. And this entire chapter of reasoning is precisely what evaporates — and must be re-derived from scratch — when moving to Solid-State Drives (SSDs), which have no platters, no seek arm, and no rotational latency at all, making this geometric model both essential background and a foil for understanding why flash storage is architecturally so different.

Ask the tutor: How would the access-time formula and the cylinder/LBA model need to be rewritten once seek time and rotational latency disappear entirely on an SSD?