A database can store the same 8 KiB page on a hard disk drive or a solid-state drive. To the database, the operation still looks like a read or write at a file offset. Below that interface, however, the two devices do radically different physical work.

An HDD may move an arm to the correct track and wait for a rotating platter. An SSD may look up an address in a mapping table, read a flash page, or relocate valid data before it can reuse an erase block. These differences affect latency, throughput, request ordering, device lifetime, and the kinds of work the operating system should avoid.

The operating system needs a common way to use both devices without exposing every mechanical or electrical detail to applications. Modern storage therefore presents a logical block interface: the host requests numbered ranges of blocks, while the device controller translates those requests into operations on its physical medium.

The operating system usually addresses storage logically. The device decides how those logical addresses map to its physical media.

This abstraction is the starting point for understanding both HDDs and SSDs.

Main memory is byte-addressable. A CPU can request a load from a particular memory address and use the returned value directly in an instruction.

Persistent storage is normally used differently. The operating system submits commands such as:

A logical block address, or LBA, is a number identifying a fixed-size block in the address space exposed by a storage device. If a device exposes 512-byte logical blocks, LBA 8,000 begins at:

The host does not normally say “use platter 2, track 91” or “program flash die 3, page 700.” It sends a range of LBAs to the device controller.

The controller is part of the storage device. It accepts commands, manages internal queues and buffers, operates the medium, detects some errors, and reports completion. Its firmware hides many medium-specific details from the operating system.

This common contract has limits. It makes different devices usable through similar requests, but it does not make them behave alike. The cost of accessing one LBA can depend heavily on what the device had to do internally.

A logical block is also not a promise about one particular physical unit. It is an address in the device's interface. HDD firmware can remap sectors, and SSD firmware routinely maps logical blocks onto different flash pages.

A hard disk drive stores bits magnetically on rotating platters. Its major physical components include:

Each surface is organized into concentric tracks, running from an outer track at the edge to inner tracks near the spindle, and each track is divided into sectors. The read/write head sits at the end of an arm that pivots from a fixed actuator point, sweeping the head inward and outward across those tracks. The drive's firmware maps the LBA space presented to the operating system onto physical sectors. Modern operating systems do not need to know the exact platter geometry.

Reading from an HDD

To read data, the drive must first position the correct head over the target track. This mechanical movement is called a seek.

The platter then has to rotate until the desired sector passes under the head. This wait is rotational latency. Once the sector reaches the head, the drive transfers the data as the platter continues to rotate.

The operation therefore has three qualitatively different parts: moving to the track, waiting for the sector to rotate under the head, and transferring the requested bytes.

The seek and rotational wait do not move useful application data, but they can dominate the time taken by a small request.

Writing to an HDD

An HDD write follows a similar positioning process. Once the target sector is under the head, the drive changes the magnetic state of the recording surface.

Conventional magnetic recording can overwrite a physical sector in its existing location. The device may still remap a defective sector or perform error-correction work, so the physical operation is not always as simple as the logical request suggests.

Why access order matters

Suppose a drive receives requests for sectors in three distant regions named A, B, and C, ordered from the outer tracks toward the inner tracks. Serving them as A, C, B requires the arm to travel across much of the platter and then move back. Serving A, B, C requires less head movement.

This is why physical locality matters so much for an HDD. Nearby requests can often be served with less mechanical repositioning. A large sequential transfer lets the drive spend more time moving data and less time seeking. A stream of small random requests may force repeated seeks and rotational waits.

The operating system can use the device's rotational nature when organizing pending requests. The exact scheduling policies belong above the hardware, but their motivation comes directly from these mechanics.

HDDs still hide complexity

An HDD is not a passive array of perfectly reliable sectors. Its controller performs error correction, retries marginal reads, and replaces unusable sectors with spare locations.

This means two adjacent LBAs are logically adjacent but not guaranteed to remain physically adjacent after remapping. It also means an unusually slow read can be the controller retrying a difficult sector rather than ordinary queueing.

The LBA interface remains valuable because the host can use the drive without managing these details. It should not be mistaken for a literal map of the platter.

A solid-state drive stores data in NAND flash memory. It has no moving arm and no rotating platter.

An SSD usually contains:

Removing mechanical positioning changes storage behavior dramatically. Reading one flash location does not require a seek across the device, so random access is much less expensive than on an HDD. But flash introduces its own constraints.

NAND reads, programs, and erases

NAND flash supports three fundamental operations:

The crucial asymmetry is:

An SSD can read and program at page granularity, but it must erase at the much larger erase-block granularity.

Flash cannot freely overwrite an already programmed page in place. Before those cells can be programmed again, the containing erase block must be erased. Erasing the block also affects all the other pages inside it.

If the operating system had to manage this rule directly, ordinary block writes would be extremely awkward. The SSD controller hides it through a translation layer.

The flash translation layer

The flash translation layer, or FTL, maps host-visible LBAs to physical flash pages.

Imagine that LBA 120 currently maps to physical page P7. When the host overwrites that LBA, the SSD can program the new data into a different erased page, such as P42, and change the mapping:

The same logical address now points somewhere else. The old page still holds data, and nothing references it, which is what the garbage collector later has to clean up.

From the operating system's perspective, LBA 120 was overwritten. Inside the SSD, the update was out of place. The old physical page became stale, and the logical address now points elsewhere.

The FTL also helps the controller distribute writes, replace failing flash locations, run error correction, and access several flash components in parallel. The mapping is a core part of the drive's persistent state: losing it would make the host's LBA space meaningless.

Garbage collection

Out-of-place updates leave stale pages scattered across erase blocks. Eventually, the SSD needs reusable erased blocks.

Suppose an erase block contains six pages:

Erasing works on the whole block, so the three valid pages have to be copied elsewhere before the stale ones can be reclaimed.

The controller cannot erase only the stale pages. It must preserve the three valid pages, erase the entire block, and make space available again. It may copy the valid pages elsewhere before erasing the complete old block and reusing its pages for future writes.

This process is garbage collection. It is internal device work caused by the mismatch between page programming and block erasure.

Garbage collection can compete with host I/O. A write that looks small to the operating system may trigger copying and erasing inside the drive, producing variable latency.

Write amplification

If the host writes 4 KiB but the SSD must also move existing valid pages, the NAND may receive more than 4 KiB of writes. The ratio between physical flash writes and host-requested writes is called write amplification.

Write amplification matters for two reasons. Extra internal work consumes device bandwidth, and NAND cells tolerate only a finite number of program/erase cycles.

Small random overwrites, little free space, and poorly aligned requests can make the controller's cleanup harder. Sequential, well-aligned writes usually give it more predictable work. The exact result depends on the SSD's firmware, available spare space, and workload.

Overprovisioning and wear leveling

SSDs reserve some flash capacity as overprovisioned space. The operating system cannot address this capacity directly. The controller uses it as working room for out-of-place updates, garbage collection, replacement of failed cells, and other internal operations.

More available erased space gives the controller greater freedom to place new data without immediately cleaning a nearly full block.

The controller also performs wear leveling. It spreads erase cycles across the flash rather than repeatedly wearing out the same small set of blocks. Logical address 120 therefore has no permanent physical home.

Wear leveling does not make flash immortal. It distributes finite endurance so that the device ages more evenly.

Discard and TRIM

Without additional information, an SSD cannot tell whether an LBA holding old data is still useful. A discard request tells the device that the host no longer needs a range of logical blocks. For ATA devices, this operation is commonly associated with the command name TRIM.

The SSD can treat those mappings as invalid and reclaim their pages during later garbage collection. Discard gives the FTL more freedom, but it does not promise that the flash cells are erased immediately.

Internal parallelism

An SSD controller can operate across multiple flash channels, packages, dies, and planes. Independent requests may therefore execute concurrently.

This makes request concurrency valuable. A single request stream may leave much of the hardware idle, while several outstanding requests let the controller use more internal units at once.

The device still has limits. Reads, programs, erases, garbage collection, and error correction can contend for the same internal resources. An SSD has no seek time, but it does not have uniform or zero access time.

The physical medium describes where data is stored. The device interface describes how the host submits commands and receives completions.

SATA is used by both HDDs and SSDs. Its command model grew from an era dominated by disks and provides a relatively small, centralized queue.

NVMe is a storage protocol designed for nonvolatile memory and commonly carried over PCI Express in local systems. It supports many independent queues and many outstanding commands, allowing operating systems to spread submission and completion work across CPUs and make better use of SSD parallelism.

An operating system can associate different NVMe queue pairs with different CPUs:

A CPU places commands in a submission queue. The controller processes commands and records results in a completion queue. Multiple queue pairs reduce contention on one shared queue and let the device keep several flash channels or dies busy.

NVMe does not make every individual flash operation instant. Its queue design reduces protocol overhead and makes concurrency easier to expose. Benefits appear when the device and workload have enough independent work to use that concurrency.

HDD and SSD describe physical storage technologies; SATA and NVMe describe host-to-device interfaces. A SATA SSD and an NVMe SSD can use similar NAND flash yet expose very different queueing capacity and command overhead.

In a virtual machine or cloud system, the visible device may be virtual. The guest still sees a block interface and queue behavior, but it may not know whether the provider uses local NVMe drives or remote storage underneath.

HDDs and SSDs can both present an array of logical blocks, but the operating system records device properties that help it make better decisions.

For a rotational device, reducing head movement and combining nearby work can greatly improve efficiency. For a non-rotational device, mechanical ordering is irrelevant, but request concurrency and queue placement still matter.

The operating system may learn properties such as:

These are reported capabilities, not a full explanation of what the hardware will do. Device firmware still controls mapping, retries, and internal scheduling.

The distinction also affects capacity planning. An HDD can be an economical choice for large sequential datasets, backups, or infrequently accessed objects. An SSD is usually a better fit for latency-sensitive random access, such as database indexes. The right choice also depends on required throughput, endurance, failure model, power, cost, and the storage service surrounding the device.

“SSD is faster” is directionally useful but operationally incomplete. A backend engineer needs to ask which workload, request size, queue depth, interface, and device class are being compared.

Linux exposes useful block-device properties without requiring a benchmark. The following command lists whole devices and several reported attributes:

A simplified result might look like:

ROTA is 1 for a device reported as rotational and 0 for a non-rotational device. TRAN describes the transport when Linux can determine it.

The same properties are available through sysfs. Replace the device name with one present on the machine:

These values must be interpreted in context. A storage controller may expose one logical device backed by several physical devices. A USB bridge may omit capabilities. A virtual machine may report a non-rotational virtual disk without revealing the provider's physical medium.

The output describes the interface Linux sees. It does not bypass the storage abstraction.

Storage devices present logical block addresses so the operating system can issue a common set of read and write requests without managing physical media directly. Logical blocks, HDD sectors, NAND pages, and NAND erase blocks are related units, but they are not interchangeable.

An HDD stores data magnetically on rotating platters. Small random requests can spend substantial time seeking and waiting for rotation, while sequential access reduces mechanical movement. An SSD stores data in NAND flash. Its controller uses a flash translation layer, out-of-place updates, garbage collection, overprovisioning, and wear leveling to hide flash's erase-before-write constraint.

The storage medium is separate from the command interface. SATA offers a relatively limited queueing model, while NVMe uses multiple submission and completion queues to expose SSD parallelism efficiently. Firmware, remapping, and virtualized storage still add layers between a logical request and the physical medium. The practical mental model is to reason from the interface the operating system sees while remembering the physical work hidden underneath it.