Learning Databases from the Ground Up: Disks and Blocks

Hello, I'm Maneshwar. I'm working on FreeDevTools online currently building **one place for all dev tools, cheat codes, and TLDRs* — a free, open-source hub where developers can quickly find and use tools without any hassle of searching all over the internet.*

If you truly want to understand databases, not just use them, but reason about their performance, durability, and failure modes you have to start below SQL, below query planners, and even below storage engines.

You have to start with the disk.

This post kind of kicks off a journey into database internals by grounding ourselves in how persistent storage actually works.

Almost every design decision in databases—buffer pools, WAL, B-Trees, checkpoints, compaction—exists because of the physical properties and limitations of disks.

Disks as Persistent Storage

Disks are the most widely used online persistent storage devices.

From a logical perspective, a disk can be viewed as a large array of fixed-size blocks.

A block is a contiguous sequence of bytes, commonly sized at:

• 1024 bytes
• 2048 bytes
• 4096 bytes

These blocks are the unit of data transfer between the disk and the host computer system.

The operating system never reads or writes individual bytes on disk—it always deals in full blocks.

Although disks support direct addressing and allow blocks to be accessed in arbitrary order, “reasonable speed” here is relative.

Compared to memory, disks are painfully slow, and that slowness defines how databases are designed.

Physical Structure of a Disk

To understand disk behavior, we need to understand how a disk is physically built.

A disk consists of multiple flat, circular metallic plates called platters.

These platters are made of highly polished glass or ceramic materials and coated with a thin layer of magnetic material capable of storing information.

• All platters are stacked on a single spindle
• The spindle rotates at a constant, high speed
• Each platter surface has its own read-write head
• All read-write heads are attached to a single arm

When the arm moves, all heads move together in unison, positioning themselves over corresponding locations on every platter surface.

This mechanical coupling is one of the main reasons disk access has non-trivial latency.

Tracks, Sectors, and Cylinders

Before a disk can store data, its surfaces must be organized.

Each platter surface is divided into concentric circular tracks thin rings centered around the spindle.

Tracks at the same arm position across all platter surfaces collectively form a cylinder.

Each track is further divided into sectors:

• A sector is the smallest unit of data that can be read or written
• Sector size is fixed at manufacturing time
• It cannot be changed later
• A track may contain hundreds of sectors

From the operating system’s point of view, disk space is abstracted as blocks, but physically:

A block is made up of one or more contiguous sectors on the same track.

When formatting a disk, the block size is typically configured as a multiple of the sector size.

Each block can be uniquely identified by a tuple:

(cylinder number, track number, starting sector number)

This mapping between logical blocks and physical layout heavily influences access cost.

Disk Access Overheads

The CPU cannot directly operate on disk data.

Even if only a few bytes are needed, the entire block must be read into main memory.

A disk access consists of three major time components:

1. Seek Time Time required to move the disk arm to the correct cylinder.
2. Rotational Latency Time spent waiting for the desired sector to rotate under the read-write head.
3. Transfer Time Time required to transfer data between disk and main memory.

These costs are not theoretical, they dominate real-world performance.

This is why databases try aggressively to minimize disk I/O and why sequential access patterns matter so much.

To reduce overhead, disks often employ techniques like sector interleaving and sector skewing.

Disk Operations: Read, Write, and Sync

At a minimum, a disk controller supports two operations:

• Read(block_address) Returns the contents of the block without modifying it.
• Write(block_address, value) Overwrites the existing block contents with the new value.

A write is an in-place update, the old data is destroyed.

Modern disks often include internal caches, meaning a write may not reach the physical disk surface immediately. Because of this, databases rely on an additional operation:

• Sync / Flush Forces cached data to be written to the disk surface.

Without proper syncing, durability guarantees become meaningless—especially after crashes or power failures.

The Problem of Non-Atomic Writes

One critical detail that database systems cannot ignore is that disk writes are not atomic.

A write operation can fail midway for example, during a power loss—leaving the block only partially updated.

This results in corrupted data, which may not even be detected by the operating system’s parity checks.

This reality is the reason databases:

• Use write-ahead logging (WAL)
• Avoid overwriting data blindly
• Rely on checksums, redo logs, and recovery protocols
• Treat disks as unreliable, even when hardware claims otherwise

Database designers must explicitly plan for partial writes and silent corruption.

👉 Check out: FreeDevTools

Any feedback or contributors are welcome!

It’s online, open-source, and ready for anyone to use.

⭐ Star it on GitHub: freedevtools