Disk Structure & Layout

Before bytes become files, before files become directories, there’s the raw geometry of spinning platters and precise magnetic encoding. Understanding how disks are structured—how the operating system speaks to raw metal—explains a lot about why file systems work the way they do. This isn’t ancient history; the concepts directly impact how we partition, format, and troubleshoot storage today.

Modern SSDs have abstracted away much of this complexity, but the underlying models persist. MBR and GPT partition tables still define how drives are divided. Understanding CHS and LBA explains why certain limits exist and why a “2TB limit” haunts older systems. The geometry of storage shapes everything from file system choices to backup strategies.

Introduction

When to Use / When Not to Use

Understanding disk structure is essential for system administration, troubleshooting, and performance optimization.

When disk structure knowledge matters:

• Setting up new systems with proper partitioning
• Troubleshooting boot issues and partition problems
• Recovering data from damaged partitions
• Working with legacy systems that hit addressing limits
• Configuring RAID and understanding redundancy

When you can ignore it:

• Working purely with cloud block storage (abstracted away)
• Using container systems with volumes
• Dealing with fully abstracted storage (some NAS systems)
• High-level application development (file I/O handles this)

Architecture or Flow Diagram

graph TD
    A[Logical Block Address LBA] --> B[Host System]
    B --> C[Storage Controller]
    C --> D[Disk Firmware]
    D --> E[Physical Media]

    F[CHS Geometry] --> C
    G[Partition Table MBR/GPT] --> F

    style A stroke:#ff00ff,stroke-width:2px
    style G stroke:#ff00ff,stroke-width:2px

The diagram shows the translation from logical addressing (LBA) to physical media. The partition table sits between the host’s view of the drive and the actual physical layout.

Core Concepts

CHS Addressing: The Old Geometry

Cylinder-Head-Sector (CHS) addressing was the original way to specify disk locations. Each component maps to a physical aspect of the drive:

• Cylinder: The set of tracks at the same radial position across all surfaces
• Head: Which read/write head is active (which surface)
• Sector: Which sector within the track (typically 512 bytes)

graph TD
    A[Disk Platter] --> B[Concentric Tracks]
    B --> C[Track 0 outermost]
    B --> D[Track N innermost]

    E[Cylinder] --> F[Track on Surface 0]
    E --> G[Track on Surface 1]
    E --> H[Track on Surface N]

    style C stroke:#ff00ff
    style D stroke:#ff00ff

With CHS, to read address (cylinder 1024, head 3, sector 50), the controller moves heads to the third surface, positions at the 1024th track, and waits for sector 50 to rotate under the head.

Limitations:

• Maximum 8GB with standard CHS (1024 cylinders × 16 heads × 63 sectors × 512 bytes)
• Drives often reported fake geometry to work around BIOS limits
• Translation layers made the situation more complex

LBA: The Modern Standard

Logical Block Addressing (LBA) simplifies everything to a single number: the sequential sector number from zero.

• LBA 0 = first sector (cylinder 0, head 0, sector 1)
• LBA 1 = second sector
• LBA n = (n+1)th sector

// LBA to CHS conversion (simplified)
void lba_to_chs(uint32_t lba, uint16_t *cyl, uint8_t *head, uint8_t *sector) {
    uint32_t sectors_per_track = 63;  // Traditional value
    uint32_t tracks_per_cylinder = 16; // Traditional value

    *sector = (lba % sectors_per_track) + 1;
    uint32_t temp = lba / sectors_per_track;
    *head = temp % tracks_per_cylinder;
    *cyl = temp / tracks_per_cylinder;
}

LBA-48 (48-bit LBA) supports drives up to 144 petabytes—more than enough for current storage needs.

Disk Geometry and Zones

Modern drives organize sectors into zones:

graph LR
    A[Zone 0<br/>Outer tracks<br/>Higher density<br/>Faster] --> B[Zone 1]
    B --> C[Zone N<br/>Inner tracks<br/>Lower density<br/>Slower]

    style A stroke:#ff00ff,stroke-width:2px
    style C stroke:#ff00ff,stroke-width:1px

Outer zones store more sectors per track than inner zones. This “zoned recording” maximizes capacity while maintaining constant data rate across the drive. The firmware handles the translation, presenting a uniform LBA space to the host.

Partition Schemes

MBR: The Legacy Standard

Master Boot Record occupies the first 512 bytes of the disk:

graph TD
    A[MBR Structure 512 bytes] --> B[Boot Code 446 bytes]
    A --> C[Partition Table 64 bytes]
    A --> D[Magic Number 0x55AA 2 bytes]

    C --> E[Partition 1 16 bytes]
    C --> F[Partition 2 16 bytes]
    C --> G[Partition 3 16 bytes]
    C --> H[Partition 4 16 bytes]

    style B stroke:#ff00ff
    style D stroke:#ff00ff

Each partition entry stores:

• Boot flag: 0x80 for bootable, 0x00 otherwise
• Starting CHS: First sector location
• Partition type: File system identifier (0x83 = Linux, 0x07 = NTFS, 0x0C = FAT32)
• Ending CHS: Last sector location
• Starting LBA: First sector as 32-bit value
• Size: Number of sectors as 32-bit value

MBR Limitations:

• Maximum 2TB per partition (32-bit sector count)
• Maximum 4 primary partitions (or 3 primary + 1 extended)
• No backup partition table
• No checksum for partition data

GPT: The Modern Standard

GUID Partition Table removes MBR’s limitations:

graph TD
    A[GPT Layout] --> B[Protective MBR 512 bytes]
    A --> C[Primary GPT Header 92 bytes]
    A --> D[Primary GPT Array 16KB min]
    A --> E[Backup GPT Header]
    A --> F[Backup GPT Array]

    style B stroke:#00fff9
    style C stroke:#ff00ff
    style E stroke:#00fff9
    style F stroke:#00fff9

GPT Advantages:

• Supports drives up to 8ZB (using 64-bit sector addresses)
• Unlimited partitions (practical limit ~128)
• Backup GPT headers at end of disk
• CRC32 checksums for integrity
• Unique partition GUIDs for reliable identification

Partition Type Identifiers

Common MBR partition types:

Type	Description
0x83	Linux
0x82	Linux swap
0x8E	Linux LVM
0x07	Windows NTFS
0x0C	FAT32
0xEE	GPT protective
0xEF	EFI System Partition

Production Failure Scenarios

Scenario 1: MBR Corruption

What happened: A server’s first drive failed catastrophically. The data recovery team retrieved most files, but the partition table was gone. Without it, the operating system couldn’t find where partitions began and ended.

Detection:

# Check for valid GPT/MBR signature
sudo fdisk -l /dev/sda | grep -E "Disklabel|GPT|MBR"

# Try to identify partitions with testdisk
sudo testdisk /dev/sda

Mitigation:

• Backup partition table regularly:

  sudo sfdisk -d /dev/sda > partitions_backup.txt

• Use GPT which has backup headers

• Keep rescue media with partition tools

• Clone partition table when setting up similar systems

Scenario 2: Overlapping Partitions

What happened: A user attempted to resize a partition using a disk management tool. The tool crashed mid-operation, leaving overlapping partitions. The kernel refused to mount the file system, and fsck failed.

Detection:

# Use parted to detect overlaps
sudo parted /dev/sda
(parted) align-check optimal 1  # Check partition 1 alignment
(parted) align-check optimal 2  # Check partition 2 alignment

# Check partition table for overlaps
sudo gdisk -l /dev/sda | grep -A 4 "unique GUIDs"

Mitigation:

• Always backup before partition operations
• Use tools that handle interruptions gracefully (parted vs fdisk)
• Use rescue mode with TestDisk for recovery
• Consider recreating partitions and restoring from backup

Scenario 3: 2TB Limit Encounter

What happened: A company purchased a 4TB drive for backup. The system only saw 2TB. The drive was using MBR partitioning, which maxes out at 2TB with 512-byte sectors.

Detection:

# Check partition table type
sudo parted /dev/sda
(parted) print

# See output like:
# Model: ATA ST4000DM000-1F2 (scsi)
# Disk /dev/sda: 4000GB
# Partition table: msdos  <-- This is MBR!

Mitigation:

• Convert to GPT using gdisk:

  sudo gdisk /dev/sda
  # Type 'w' to convert MBR to GPT (backup MBR first!)

• For boot drives, ensure UEFI boot support exists

• Plan for GPT on drives larger than 2TB

Trade-off Table

Aspect	MBR	GPT	Notes
Max Drive Size	2TB	8ZB	MBR limited by 32-bit sector count
Max Partitions	4 primary	128 primary	GPT practical limits
Backup	None	Header + array at end	Automatic with GPT
Boot Support	BIOS only	UEFI required for boot	Legacy systems use MBR
Integrity	None	CRC32 checksums	GPT validates structure
Partition IDs	1-byte type	128-bit GUID	GPT more precise

Implementation Snippet

Reading Partition Table with Python

import struct

def read_mbr(device_path):
    """Read and parse MBR partition table."""
    with open(device_path, 'rb') as f:
        # Read boot sector (512 bytes)
        boot_sector = f.read(512)

        # Verify magic number
        if boot_sector[510:512] != b'\x55\xaa':
            raise ValueError("Invalid MBR signature")

        # Parse partition table (64 bytes starting at offset 446)
        partitions = []
        for i in range(4):
            entry_offset = 446 + (i * 16)
            entry = boot_sector[entry_offset:entry_offset + 16]

            if entry[0] == 0:  # Empty partition
                continue

            partition = {
                'boot_flag': entry[0],
                'start_head': entry[1],
                'start_sector_cylinder': struct.unpack('<H', entry[2:4])[0],
                'type': entry[4],
                'end_head': entry[5],
                'end_sector_cylinder': struct.unpack('<H', entry[6:8])[0],
                'start_lba': struct.unpack('<I', entry[8:12])[0],
                'size_sectors': struct.unpack('<I', entry[12:16])[0],
            }
            partitions.append(partition)

        return partitions

def print_partitions(device_path):
    """Display partition information."""
    TYPE_NAMES = {
        0x07: 'NTFS/HFS+',
        0x83: 'Linux',
        0x82: 'Linux Swap',
        0x8E: 'Linux LVM',
        0x0C: 'FAT32',
        0xEE: 'GPT Protective',
        0xEF: 'EFI',
    }

    parts = read_mbr(device_path)
    for i, p in enumerate(parts):
        ptype = TYPE_NAMES.get(p['type'], f'Unknown (0x{p:02x})')
        size_gb = (p['size_sectors'] * 512) / (1024**3)
        print(f"Partition {i+1}: {ptype}, Start LBA: {p['start_lba']}, "
              f"Size: {size_gb:.2f} GB")

if __name__ == "__main__":
    import sys
    print_partitions(sys.argv[1] if len(sys.argv) > 1 else "/dev/sda")

Inspecting GPT with bash

#!/bin/bash
# gpt_inspect.sh - Display GPT partition information

DEVICE=${1:-/dev/sda}

echo "=== GPT Partition Table for $DEVICE ==="

# Check for GPT
if ! sudo gdisk -l "$DEVICE" 2>/dev/null | grep -q "GPT:"; then
    echo "Not a GPT disk"
    exit 1
fi

# List partitions
sudo gdisk -l "$DEVICE" <<< "p"

# Show partition details
echo ""
echo "=== Detailed Partition Info ==="
for part_num in $(seq 1 128); do
    info=$(sudo gdisk -l "$DEVICE" 2>/dev/null | grep "^$part_num ")
    if [ -n "$info" ]; then
        echo "$info"
    fi
done

# Show backup GPT location
echo ""
echo "=== GPT Backup Header Location ==="
sudo gdisk -l "$DEVICE" | grep -E "Backup|Sector"

Observability Checklist

Monitoring disk structure health:

• fdisk -l /dev/sdX: List partition table and verify signatures
• gdisk -l /dev/sdX: Show GPT information and GUIDs
• parted /dev/sdX print: Display partition layout
• lsblk: Show block devices and their hierarchy
• blkid: Show UUID and TYPE for each partition

Key checks:

# Verify MBR/GPT signatures
sudo fdisk -l /dev/sda 2>/dev/null | grep "Disklabel"
# Should show: Disklabel type: dos (MBR) or gpt

# Check for backup GPT
sudo gdisk -l /dev/sda | grep "Backup GPT"
# Should show location at end of disk

# Monitor partition alignment
sudo parted /dev/sda align-check opt
# Should show "1 aligned" for each partition

# Verify partition doesn't exceed disk size
cat /proc/partitions

Common Pitfalls / Anti-Patterns

Secure Partition Deletion

Simply deleting partitions doesn’t erase data. For compliance:

# Overwrite entire drive with zeros (slow but thorough)
sudo dd if=/dev/zero of=/dev/sda bs=1M status=progress

# Use random data for better security
sudo shred -v -n 1 /dev/sda

# For quick format (not secure)
sudo hdparm --secure-erase-all /dev/sda

UEFI Secure Boot Considerations

• EFI System Partition (ESP) must be FAT32
• ESP size recommendation: 100-500MB
• ESP must be flagged as “EFI boot” in partition table

# Create EFI partition with gdisk
# Type: EF00 (EFI System Partition)
sudo gdisk /dev/sda
Command: n
Partition number: 1
First sector: [default]
Last sector: +512M
Hex code: EF00

Partition UUIDs for Compliance

GPT assigns unique GUIDs to each partition. Document these:

# List partition UUIDs
sudo blkid

# Or with gdisk
sudo gdisk -l /dev/sda | grep -E "Partition GUID|unique"

# Export for documentation
sudo blkid -s UUID -s TYPE -s LABEL > partition_ids.txt

Common Pitfalls / Anti-patterns

1. Converting MBR to GPT Without Backup

# BAD: Converting without backup
sudo gdisk /dev/sda
Command: m  # Load MBR, convert in place
Command: w  # WRITE (data loss possible if interrupted!)

# GOOD: Backup first, then convert
sudo sfdisk -d /dev/sda > mbr_backup.txt
sudo dd if=/dev/sda of=mbr_sector_512.img bs=512 count=1
# Now safe to convert

2. Creating Partitions That Overlap

# BAD: Manually calculating can cause overlap
# Partition 1: 2048-4096 (1MB)
# Partition 2: 4095-8192 (overlaps!)
#                 ^^^ Should be 4096, not 4095

# GOOD: Use tools that prevent overlap
sudo parted /dev/sda mkpart primary ext4 2048s 4096s
sudo parted /dev/sda mkpart primary ext4 4096s 8192s
# parted validates and prevents overlap

3. Ignoring Alignment

Modern disks and SSDs require 1MB alignment (2048 sectors of 512 bytes):

# BAD: Default alignment might be wrong
sudo fdisk /dev/sda  # May create misaligned partitions

# GOOD: Specify alignment
sudo parted /dev/sda mkpart primary ext4 2048s 100%
# Use sector numbers that are multiples of 2048

4. Boot Flag Confusion

MBR uses the boot flag to indicate which partition is bootable. Modern UEFI ignores this:

# Set boot flag (only matters for BIOS boot)
sudo fdisk /dev/sda a 1  # Set boot flag on partition 1

# Clear boot flag
sudo fdisk /dev/sda a 0  # Clear boot flag

Quick Recap Checklist

• CHS addressing maps to physical disk geometry; LBA is the logical replacement
• MBR supports max 2TB and 4 primary partitions; GPT removes these limits
• GPT includes backup headers at end of disk for recovery
• Always backup partition table before making changes
• Convert MBR to GPT for drives larger than 2TB
• Use sector alignment of 2048 (1MB) for modern disks
• Partition type codes identify the file system; GPT uses 128-bit GUIDs

Interview Questions

Further Reading

Topic-Specific Deep Dives:

• UEFI and GPT: Explore how UEFI firmware interacts with GPT during boot. The EFI System Partition (ESP) contains bootloaders and must be FAT32. Understanding UEFI boot sequence explains why some systems refuse to boot from MBR disks.

• Zoned Recording: Modern HDDs and some SSDs use zoned recording (shingled magnetic recording on HDDs, zoned namespaces on SSDs). This affects how file systems allocate blocks and why outer zones perform differently than inner zones.

• 512e vs 4Kn Sector Sizes: The “512e” (512-byte emulation) vs “4Kn” (4KB native) distinction causes confusion in enterprise storage. Understanding why requires examining how modern drives present their geometry to the host system.

• Disk Partition Alignment: The 1MB alignment requirement (2048 sectors) ensures partitions align with SSD erase block boundaries and RAID stripe sizes. Explore why misalignment causes performance degradation on SSDs.

• Advanced Format (AF) Drives: Enterprise drives use 4KB native sectors. Study how operating systems handle these drives and why legacy 512-byte assumptions still cause problems in some configurations.

Conclusion

Disk structure determines how storage devices present themselves to the operating system. CHS addressing reflected physical disk geometry, but LBA simplified everything to sequential sector numbers — the translation from logical to physical now happens entirely within the drive firmware. MBR’s 2TB limit and 4-partition constraint pushed the industry toward GPT, which offers near-unlimited partitions, checksums for integrity, and backup headers at the end of the disk.

Partition schemes define the layout, but file systems define the organization within those partitions. The partition table itself is just the starting point — understanding how the OS interprets that table and locates file system structures underneath prepares you for recovery scenarios, capacity planning, and dual-boot configurations.

For deeper learning, explore how UEFI firmware interacts with GPT and the EFI System Partition, how zoned recording affects SSD behavior, and how the distinction between logical and physical sector sizes (512e vs 4Kn) still causes confusion in enterprise environments. The fundamentals of disk geometry underpin everything from storage array configuration to data recovery.