Day 14: A Disk Is Not Just One Thing

Linux Disk Schematic — How Linux Works by Brian Ward

Previously, we saw how Linux detects a device the moment it is connected. Today is about what that device actually looks like on the inside, and in this case, we are looking at a disk. It turns out a disk is not a single flat thing. It is a stacked with layers, each having a specific role, and you cannot use any layer without understanding the one beneath it.

The Stack Inside a Disk

When the kernel makes a disk available as /dev/sda, it is presenting the whole disk as a block device. But that block device contains multiple components arranged in a hierarchy.

At the top is the partition table. This is a small area at the start of the disk that describes how the rest of the disk is divided. It is not data, but like a map.

Below the partition table are the partitions themselves. Each partition is a defined portion of the disk, having a start point and an end point. The kernel treats each partition as its own block device, which is why partitions have names like /dev/sda1 and /dev/sda2.

Inside a partition is the filesystem data structure. This is what organises the partition into something a user can actually work with: directories, filenames, permissions, metadata. ext4, FAT32, NTFS are all examples of filesystem types that can live inside a partition. (We will come to filesystem in a latter post).

At the bottom is the actual file data, the raw bytes that make up the contents of files.

To read a file, Linux consults the partition table to find the partition, reads the filesystem structure on that partition to locate the file, then reads the file data itself. Four layers, every time.

This is why partitioning and creating a filesystem are separate steps. The partition table only defines boundaries. The filesystem is a much more involved structure built inside those boundaries. Changing one does not automatically change the other.

Two Kinds of Partition Tables

There are two main partition table formats in use.

The older one is MBR, short for Master Boot Record. It dates back to early PC days and has limitations. It supports a maximum of four primary partitions. To get around this, one of those four can be designated as an extended partition, which can then contain logical partitions inside it. It is a workaround that has been in use for decades.

The newer one is GPT, short for GUID (Globally Unique Identifier) Partition Table. It does not have the four-partition limit, supports much larger disks, and is what most modern systems use.

Running parted -l shows the partition table on any disk. The output distinguishes between the two: MBR shows as msdos, GPT shows as gpt.

How Linux Works by Brian Ward

Modifying Partition Tables

There are two major tools for modifying partition tables: parted and fdisk.

The important difference is how they handle changes. With fdisk, nothing happens to the actual disk until the user explicitly writes the changes confirming it with a command. Every action before that point is just a design. The disk is untouched. This makes fdisk safer for learning because mistakes can be abandoned with q before any damage is done.

With parted, changes happen immediately as commands are issued. There is no review step. Partitions are created, modified, and deleted in real time.

This distinction matters. Running the wrong parted command does not give a second chance.

The SSD Changes Some Assumptions

Spinning disks have a physical head that moves across a platter to read data. The geometry of that movement, cylinders and sectors, shaped how partitioning worked for decades. Partitions were aligned to cylinder boundaries because that made reads faster: the head could read a continuous band without repositioning.

Top-down view of a disk — How Linux Works by Brian Ward

SSDs have no moving parts. There is no head, no platter, no cylinder. Random access costs the same regardless of where on the disk the data lives, meaning that the drive reads any location by sending an electrical signal through circuits. Whether the data is at the very start of the drive or at the very end, the time to retrieve it is essentially the same.

But SSDs introduce a different constraint: partition alignment. An SSD reads data in chunks called pages, typically 4,096 or 8,192 bytes. If a partition starts at an offset that does not align to a page boundary, a single read operation that crosses the boundary requires two page reads instead of one. For something as common as reading a directory listing, that doubles the work.

Modern partitioning tools handle this automatically by aligning new partitions to 1MB boundaries, which is a multiple of every common page size. On most systems today, there is nothing to configure. But understanding why alignment matters becomes relevant when working with high-throughput storage systems where read performance is being measured and tuned.

To summarise it all, a disk presented as /dev/sda is not a single flat object. It is a partition table sitting on top of partitions, each containing a filesystem, each containing file data. Every layer has to be in place before the one above it can function.

Just like Day-12, a major takeaway is using by-id paths over raw device names and knowing what layer a problem lives in when storage behaves unexpectedly. If a disk is visible but not readable, the partition table might be missing. If the partition exists but files cannot be created, the filesystem might not have been formatted. Knowing the stack makes the diagnosis faster.

On to Day 15.

Following along my 30-day Linux journey. If you are learning too, feel free to drop a comment.