Anatomy of a Disk

A storage device is exposed as a block device, such as /dev/sda or /dev/nvme0n1. It can contain a partition table, whose entries describe regions exposed as child block devices. A partition can then hold a filesystem, swap signature, RAID member, encryption container, logical-volume physical volume, or another data format.

These layers are independent: not every disk has a partition table, not every partition contains a filesystem, and a filesystem can reside on a logical volume or whole device.

Partition Tables and Boundaries

A partition table records start positions, lengths, type identifiers, and scheme-specific attributes. The kernel reads it to create partition block devices such as /dev/sda1 or /dev/nvme0n1p1.

Partition boundaries must not overlap in ordinary layouts. Space outside all entries is unallocated from the partition table's perspective, though it can still contain old signatures or data. Changing a table does not automatically move filesystem contents to match new boundaries.

MBR Partitioning

The legacy DOS/MBR scheme stores its primary table in the first logical sector. It has four primary table entries. One entry can describe an extended partition that acts as a container for a linked series of logical partitions, providing more than four usable regions.

With 32-bit sector addresses and 512-byte logical sectors, MBR reaches a commonly cited limit of about 2 TiB. Exact addressability depends on sector size and tool support. MBR also lacks GPT's redundant header and table copies and per-partition GUIDs.

GPT Partitioning

The GUID Partition Table, or GPT, uses 64-bit logical block addresses and normally stores a primary header and entry array near the start plus backup copies near the end of the disk. A protective MBR helps older MBR-only software avoid treating the disk as empty.

Each GPT entry includes a partition type GUID and a unique partition GUID; GPT therefore does not have only one partition type. The number of available entries is determined by the allocated table and tools, commonly far more than four, without extended or logical partitions.

GPT is normally used for UEFI boot disks, but partitioning and firmware boot mode are distinct concepts. A UEFI system also needs appropriate boot files and an EFI System Partition; GPT alone does not make a disk bootable.

Filesystem Structures Are Format-Specific

After partitioning, a filesystem creation tool writes the structures defined by that filesystem. Many formats have concepts such as superblocks, allocation metadata, directory records, and data extents or blocks, but their layout, redundancy, and terminology differ.

For example, ext filesystems use inodes and block groups, while other filesystems organize metadata through different trees or allocation structures. Do not apply one simplified “boot block, one superblock, inode table, data blocks” diagram to every filesystem.

Inspecting the Current Layout

Use read-only views before any modification:

$ lsblk -o NAME,PATH,TYPE,SIZE,PTTYPE,PARTTYPE,FSTYPE,MOUNTPOINTS
$ sudo parted --list

PTTYPE describes a detected partition-table scheme, PARTTYPE a partition type identifier, and FSTYPE a detected content signature. Detection is evidence, not a guarantee that content is healthy or safe to mount.

Device names can change, and stale signatures can confuse detection. Confirm model, serial, size, transport, persistent links, active mounts, swap, RAID, LVM, encryption, and backups before opening any partitioning tool in write mode.

Use Manage Linux Partitions and Filesystems only on disposable storage to practice these layers.

Summary

You can now separate disk layout metadata from the data formats stored within it.

1. Identify whole devices and their partition child devices.
2. Relate MBR extended partitions to legacy four-entry limits.
3. Relate GPT to redundant tables and per-partition GUIDs.
4. Treat filesystem creation as separate from partition creation.
5. Inspect every storage layer and active consumer before changes.