Disk Addressing and Partition Tables

Last update: 2024-02-16 16:23:16 +0800 +0800
Available translations: 日本語 / 中文(简体) / 中文(繁體)

Disk addresses identify sectors, while partition tables divide the resulting address space into regions. Filesystems occupy some of those regions but belong to a separate format layer. Keeping the layers distinct explains why obsolete geometry fields can coexist with modern logical addressing.

Physical and Translated CHS Geometry #

Cylinder-head-sector (CHS) addressing models a rotating disk through three coordinates:

  • Cylinder selects the same radial track position across the platter surfaces.
  • Head selects a recording surface.
  • Sector selects a numbered record within that track.

The BIOS INT 13h interface and the original IBM PC partition table encoded CHS, but their fields did not scale together. A legacy MBR entry allocates 10 bits to the cylinder, 8 bits to the head, and 6 bits to a one-based sector number. The maximum encoded geometry is therefore 1024 cylinders, 256 heads, and 63 sectors per track. With 512-byte sectors, those fields describe at most about 8.4 GB.

Real drives also began using zone bit recording, spare-sector remapping, and embedded controllers, so one fixed sectors-per-track value no longer represented the medium. BIOS and drive firmware responded with translated or synthetic geometries. A CHS tuple in an old partition entry can consequently be compatibility metadata rather than the location of a physical track.

Logical Block Addressing and Capacity #

Logical block addressing (LBA) numbers addressable sectors from zero. The host asks for LBA 0, LBA 1, and so forth; the device maps each number to its internal medium. Capacity follows directly from the number and size of logical blocks:

text
capacity in bytes = logical-block count × logical-block size

An MBR partition entry stores a 32-bit starting LBA and a 32-bit sector count. At 512 bytes per sector, the count field limits one partition to just under 2 TiB. Drives exposing 4096-byte logical blocks move that arithmetic limit, but legacy firmware and software compatibility may impose other constraints. LBA removes CHS translation; it does not make every field that stores an LBA arbitrarily wide.

MBR Bootstrap and Partition Entries #

The master boot record occupies the first 512-byte logical sector in the traditional layout. Its conventional structure is:

OffsetSizePurpose
0446 bytesBootstrap code and implementation-specific data
44664 bytesFour 16-byte partition entries
5102 bytes0x55AA signature

Each entry contains a boot indicator, partition-type byte, starting and ending CHS fields, starting LBA, and sector count. A BIOS bootstrap can inspect the active entry and load code from the selected partition. The table itself neither defines the filesystem nor guarantees that a partition contains boot code.

Extended Partitions #

Four entries proved restrictive, so MBR systems reserve partition-type values for an extended partition. The extended region contains a linked sequence of extended boot records (EBRs):

  1. The first EBR entry describes one logical partition relative to that EBR.
  2. The second entry, when present, points to the next EBR relative to the base of the containing extended partition.
  3. Following the links enumerates the logical partitions.

An extended partition is therefore a container for metadata and logical partitions, not one additional filesystem volume. Broken offsets or loops in the EBR chain can hide later partitions even when their filesystem data remains present.

Volume Boot Records #

A partition used for BIOS boot often begins with a volume boot record (VBR). For FAT, the VBR combines initial machine code with a BIOS Parameter Block describing the volume. NTFS and other bootable filesystems define their own first-sector formats. The MBR locates a partition, while the VBR and filesystem metadata interpret its contents; neither structure can substitute for the other.

GUID Partition Table #

The GUID Partition Table (GPT), standardized as part of UEFI, replaces the four-entry array and 32-bit MBR LBAs with a self-describing layout. A common disk has:

  1. a protective MBR at LBA 0;
  2. a primary GPT header at LBA 1;
  3. a primary partition-entry array;
  4. usable LBAs for partitions;
  5. a backup partition-entry array near the end of the disk;
  6. a backup GPT header in the final logical block.

The header records its own LBA, the alternate header’s LBA, usable-LBA bounds, the disk GUID, the entry-array location and shape, and CRC32 checksums for both header and entry array. The backup stores enough metadata to recover when one copy is damaged, although repair software must decide which valid copy reflects the intended layout.

Each partition entry carries a partition-type GUID, a unique partition GUID, first and last 64-bit LBAs, attributes, and a UTF-16LE name. Type GUIDs state a partition’s intended role; unique GUIDs distinguish individual partitions. Neither GUID proves which filesystem is present.

The protective MBR normally has a 0xEE entry covering the GPT disk as far as the 32-bit MBR size permits. Its purpose is defensive: an MBR-only program should see the disk as occupied rather than offering to repartition it. Hybrid MBRs duplicate selected GPT partitions in legacy entries, but the two tables can diverge and are not the standard protective layout.

Keep Addressing, Partitioning, and Filesystems Separate #

Storage tools operate at different layers:

  • A device reports logical blocks and their size.
  • MBR or GPT metadata assigns ranges of those blocks to partitions.
  • A filesystem interprets blocks within one assigned range as boot records, allocation structures, directories, and file data.

Changing a partition boundary does not resize the enclosed filesystem. Formatting a partition does not recreate its GPT entry. Likewise, a filesystem signature found at an offset can survive after its partition entry is deleted. Safe recovery and migration tools must validate all three layers rather than infer one from another.

References #

Comments

Read or comment on GitHub (sign-in required to comment)