Partition: Explanation & Insights

A disk is one slab of bytes; a partition is where you draw the lines that turn it into rooms.

What It Is

A partition is a contiguous range of a disk reserved for one purpose, marked out by an entry in a small index near the front of the disk called the partition table. That's the whole idea in one sentence: a disk is a flat, featureless sequence of sectors numbered from zero to the end, and a partition is nothing more than a note that says "sectors 2048 through 500000000 belong together — treat them as one unit." Carve a disk into three partitions and the operating system sees three independent block devices: /dev/sda1, /dev/sda2, /dev/sda3. Each one can hold a different filesystem, be mounted at a different place, even run a different operating system. To the disk itself, nothing has changed. It's still just storing bytes. The lines are pure bookkeeping.

If you've only ever written software, this is a layer you've never had to think about — the laptop came pre-partitioned, the cloud image came pre-partitioned, it all just worked. But the moment you provision a fresh server or attach a new volume, you meet the raw disk with no lines drawn on it at all, and you have to decide where they go. This page will take you from "what even is a partition" to confidently reading the layout of any Linux box, choosing MBR vs GPT, understanding why partitions start at the one-megabyte mark, and knowing the one resize operation that will eat your data if you do it in the wrong order.

There's one thing about partitions that trips up nearly everyone the first time, and the whole page builds toward making it crisp: a partition is not a filesystem, and a filesystem is not a partition. They are separate layers that happen to live next to each other. We'll nail that distinction properly in a moment — it's the muddy bit that, once clear, makes the entire storage stack click into place.

Why It Matters

The partition layout is the skeleton of a server, decided once at install time and awkward to change afterward. Get it right and you never think about it again. Get it wrong and you spend a Saturday shuffling data around to free up a partition that ran full while the one next to it sits half-empty — because partitions are hard walls, and space trapped on one side cannot help the other.

That rigidity is the double edge. A partition gives you isolation: fill up /var/log with runaway logs and it can't swallow the space your database needs on a separate partition, so a disk full on one mount doesn't take down the whole machine. But isolation cuts both ways — those same hard walls are exactly what leaves you stuck when one fills and another idles. The modern answer to that tension is LVM, which we'll get to; for now, hold the thought that fixed partitions trade flexibility for simplicity, and that trade is sometimes worth it and sometimes not.

Partitions also matter because they're where booting begins. The firmware on your server reads the partition table to find out where the bootable code lives, which is why a corrupted table can leave a perfectly healthy disk looking like a brick. Understanding the table is understanding how the machine pulls itself up by its bootstraps.

The Layers Are Separate — The One Thing to Get Right

Here is the mental model that every tutorial leaves muddy, laid out once and for all. Storage on a Linux server is a stack, and each layer knows nothing about the layers above or below it:

  disk            /dev/sda          a raw slab of sectors, knows nothing
   └─ partition   /dev/sda1         a byte range, marked in the partition table
       └─ (LVM?)  /dev/vg/lv        optional: pool partitions, slice flexibly
           └─ filesystem  ext4      structure: files, directories, permissions
               └─ mount point  /    where that structure appears in the tree

Read it top to bottom. The disk is physical hardware that stores numbered sectors and has no opinion about what's in them. A partition is a range of those sectors, defined by a table entry — it is just a byte range, nothing more. It contains no files, no directories, no concept of "free space"; it's an address book entry that says "from here to there is region one." A filesystem is the data structure — inodes, directory trees, allocation bitmaps — that someone writes inside that byte range with mkfs. And the mount point is where that filesystem gets grafted onto the directory tree so you can cd into it.

The layers are independent, and three consequences fall out of that independence — each one surprises people:

You can skip partitions entirely. A filesystem doesn't need a partition under it. You can run mkfs.ext4 /dev/sdb on a whole disk and mount it directly — no partition table at all. This is common for data disks in virtual machines and for RAID members. The filesystem neither knows nor cares whether there's a partition table above it; it just wants a byte range to live in, and a whole disk is one big byte range.
You can layer LVM in between. Instead of partition → filesystem, you do partition → LVM → filesystem. LVM pools one or more partitions into a "volume group" and hands out logical volumes you can grow, shrink, and snapshot at will — flexibility that fixed partitions can't give you. The filesystem on top still doesn't know the difference; it sees a block device like any other.
A partition with no filesystem is perfectly valid. A swap partition holds no filesystem at all — it's a raw byte range the kernel uses as overflow memory. A partition is a container; what you put in it is a separate decision.

Note

When you hear someone say "the disk is full," they almost always mean the filesystem on a partition is full — the partition itself is a fixed range that's neither full nor empty, it's just there. Keeping the layers straight in your head turns half of all storage confusion into a non-event.

Once this clicks, lsblk output stops looking like noise and starts reading like the stack diagram above — disk, then partition, then filesystem, then mount point, indented exactly in that order.

The Partition Table — MBR vs GPT

The partition table is the index that says where each partition starts and ends. There are two formats you'll meet, born 35 years apart, and on a modern server the choice is not close.

MBR (Master Boot Record) is the old guard, dating to the IBM PC of 1983. It crams the partition table into the disk's very first 512-byte sector, alongside the bootstrap code — and that tiny space is the source of all its limits. MBR allows only four primary partitions, because the table has room for exactly four 16-byte entries. It addresses sectors with a 32-bit number, which caps a disk at 2 TiB — buy a 4 TB drive, partition it with MBR, and half of it simply vanishes from view. The industry worked around the four-partition ceiling with an ugly hack: turn one primary into an extended partition, a container that holds a linked list of logical partitions inside it. It works, you'll still see it on older boxes, and it's exactly the kind of clever-but-fragile design that gets replaced.

GPT (GUID Partition Table) is the replacement, part of the UEFI standard. It fixes every MBR limit at once: 128 partitions by default (no extended/logical contortions — they're all just partitions), 64-bit sector addressing that pushes the practical disk-size ceiling into the zettabytes, and a backup copy of the table at the end of the disk so a single bad sector at the front can't orphan all your data. Every entry also carries a globally unique ID and a human-readable name. GPT pairs naturally with UEFI firmware, which is what every server bought this decade ships with.

The opinionated take, and it's not subtle: use GPT on anything modern. Full stop. There is no scenario on a current server where MBR's limits buy you anything — they only take things away. The only time you touch MBR is when you inherit an old box that already has it, or you're building media for a machine whose ancient BIOS genuinely can't boot GPT, and those machines are getting rare enough to be museum pieces. New disk, new server: GPT.

	MBR	GPT
Born	1983 (IBM PC)	~2000 (UEFI spec)
Max partitions	4 primary (more via extended + logical)	128 (typical default)
Max disk size	2 TiB	zettabytes (effectively unlimited)
Table copies	one, at the start	two — start and end of disk
Per-partition name	no	yes, plus a unique GUID
Firmware pairing	legacy BIOS	UEFI
Use it when	forced to by ancient hardware	always, on anything modern

Backstory

MBR's four-partition limit wasn't shortsightedness — in 1983, four was generous for a 10 MB disk. The limit only became a wall decades later, and the extended-partition trick was bolted on to climb over it. GPT didn't tweak the design; it threw out the 512-byte straitjacket entirely. There's a lesson in there about the cost of squeezing tomorrow's data into yesterday's sector.

Partition Types and Flags

Every entry in the table carries more than just start and end. It also has a type (sometimes called the partition ID), a code that hints at what's meant to live inside. On MBR it's a single byte: 83 for a Linux filesystem, 82 for Linux swap, 8e for a Linux LVM member, ef for an EFI System Partition. On GPT the type is a full GUID, but the idea is identical — a label declaring intent.

It's important to understand that the type is advisory, not enforced. A partition tagged 83 "Linux filesystem" doesn't contain a filesystem until you run mkfs; you can put a swap area in a partition typed 83 and Linux won't stop you. The type is a hint for tools and firmware — UEFI looks specifically for the EFI System Partition type to find bootable code, and 8e/LVM-GUID tells LVM tools "this is one of mine." Think of it as a sticky note on the door, not a lock.

GPT adds attribute flags on top of the type: a legacy_bios_bootable flag, a required flag that warns tools not to delete the partition, a read-only hint. You'll rarely set these by hand — the installer does it — but they explain why a partition manager sometimes refuses to touch a partition without an override.

/dev/sda vs /dev/sda1 — Reading the Names

Linux names disks and their partitions with a simple, learnable scheme, and getting it straight removes a whole category of beginner mistakes.

/dev/sda is the whole disk — the first SCSI/SATA/USB disk the kernel found. The trailing letter increments per disk: /dev/sdb is the second, /dev/sdc the third.
/dev/sda1 is the first partition on that disk. The number increments per partition: /dev/sda2, /dev/sda3.
NVMe drives follow a richer scheme: /dev/nvme0n1 is the whole disk (controller 0, namespace 1), and /dev/nvme0n1p1 is its first partition — note the p before the partition number, there to keep the namespace digit from blurring into the partition digit.

So /dev/sda and /dev/sda1 are not interchangeable, and confusing them is how data gets destroyed. Run mkfs on /dev/sda and you format the entire disk, wiping the partition table and every partition on it; run it on /dev/sda1 and you format just that one partition. One character, an order of magnitude of regret.

Danger

Device names are assigned at boot by probe order, and they are not stable. Add a USB stick, swap a SATA cable, or change a BIOS setting, and yesterday's /dev/sdb can become today's /dev/sda. Never destroy or format a partition by its /dev/sdX name without first confirming it's the one you mean — check the size and contents with lsblk, and reference filesystems in /etc/fstab by UUID, never by device name. The disk you wipe by stale name is always the one you needed.

How I Inspect It

When I sit down at an unfamiliar server, four commands tell me the entire storage layout, and I run them in roughly this order.

lsblk — The Layout at a Glance

lsblk (list block devices) is the first thing I reach for, because it draws the whole stack as a tree — disks, partitions, LVM, RAID, filesystems, and mount points, indented to show what sits on what:

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   480G  0 disk
├─sda1        8:1    0   512M  0 part /boot/efi
├─sda2        8:2    0     1G  0 part /boot
└─sda3        8:3    0 478.5G  0 part /
sdb           8:16   0   1.8T  0 disk
└─sdb1        8:17   0   1.8T  0 part /data

Read it exactly like the stack diagram from earlier: sda is the whole disk, sda1/sda2/sda3 are partitions indented under it, and the rightmost column shows where each is mounted. The TYPE column says disk for the device and part for each partition — a one-word reminder of which layer you're looking at. Add -f to see the filesystem on each partition, or -o NAME,SIZE,TYPE,PARTTYPE,MOUNTPOINTS to see the partition type codes.

fdisk -l — The Table, Sectors and All

When I want the partition table itself — start sectors, end sectors, and crucially the table format — I use fdisk:

fdisk -l /dev/sda

Disk /dev/sda: 480 GiB, 515396075520 bytes, 1006632960 sectors
Disklabel type: gpt
Disk identifier: 7F3A1C2E-...

Device       Start        End    Sectors   Size Type
/dev/sda1     2048    1050623    1048576   512M EFI System
/dev/sda2  1050624    3147775    2097152     1G Linux filesystem
/dev/sda3  3147776 1006630911 1003483136 478.5G Linux filesystem

The line I check first is Disklabel type: gpt — that one word tells me whether I'm dealing with a modern GPT disk or a legacy MBR one, which changes everything about what's possible. Then I glance at the Start column: notice sda1 begins at sector 2048, not sector 1. That 2048 is the alignment we'll talk about next, and seeing it there is how I confirm the disk was set up correctly.

parted -l — The Cross-Disk Summary

parted does much of what fdisk does but speaks human units natively and handles GPT a touch more gracefully for scripting. parted -l walks every disk and prints its table; I reach for it when I want to compare several disks at once or when I'm about to resize something, since parted is also the tool that does the resizing.

blkid — Type and UUID per Partition

blkid answers a narrower question: for each partition, what filesystem is on it and what's its UUID? That UUID is what belongs in /etc/fstab. It's the bridge between "this byte range" and "this specific filesystem I want mounted here, no matter how the device names shuffle at boot."

Partition Alignment — Why Everything Starts at 1 MiB

Look again at that fdisk output: the first partition started at sector 2048. At 512 bytes per sector, 2048 sectors is exactly 1 MiB of slack left empty at the front of the disk. This is not waste — it's the single most important piece of partition hygiene, and it's worth understanding why, because the cost of getting it wrong is invisible until your storage is mysteriously slow.

Modern storage does not actually work in 512-byte sectors. SSDs erase and write in much larger units (pages and blocks of kilobytes to megabytes), and "4K-native" or "Advanced Format" drives use 4096-byte physical sectors while politely pretending to offer 512-byte ones for compatibility. The hardware has a natural grid, and it strongly prefers that your reads and writes line up with that grid.

Here's what happens when they don't. Suppose a partition starts at sector 63 — the old MBR default from the 1980s, back when disks were addressed in cylinders. Now every 4 KiB filesystem block straddles the boundary between two physical 4 KiB sectors. To write one logical block, the drive must read both physical sectors it touches, modify the overlapping parts, and write both back — the dreaded read-modify-write penalty. One write becomes a read, a merge, and two writes. On an SSD this also burns through write-endurance faster, because you're rewriting sectors that didn't need to change. The throughput hit can be substantial and it never shows up as an error — just a server that's quietly slower than it should be, forever.

Starting at 1 MiB sidesteps all of it. One mebibyte is evenly divisible by every sane physical sector size, page size, and RAID stripe width you're likely to meet, so every partition — and therefore every filesystem block inside it — lands flush on the hardware's grid. The first read-modify-write you avoid pays for the megabyte a thousand times over.

Pro Tip

The good news: you almost never have to think about this. Every modern partitioning tool — parted, fdisk, and every distro installer — defaults to 1 MiB alignment automatically. The advice is simply: let the default stand. Don't hand-pick a start sector to reclaim that megabyte, and be suspicious of any disk where fdisk -l shows a first partition starting somewhere other than 2048 — it was likely partitioned by something ancient, and it may be paying the read-modify-write tax on every write.

Resizing — The Foot-Gun That Eats Data

Sooner or later a partition runs short and you want to grow it, or you want to shrink one to make room for another. This is doable, but it hides a trap that destroys data with no warning, and it comes down to the layer model from the top of the page. A partition and the filesystem inside it have two separate sizes, and they must be changed in the right order.

Growing is the safe direction, and the order is intuitive: enlarge the partition first (move its end marker outward), then grow the filesystem to fill the new space (resize2fs for ext4, xfs_growfs for XFS). The filesystem expands into ground that's already yours. Both steps can often happen live, on a mounted filesystem.

Shrinking is where people lose data, because the order is the exact reverse and it is not intuitive:

Danger

When shrinking, you must shrink the filesystem BEFORE the partition. Run resize2fs /dev/sda3 100G to shrink the filesystem first, then shrink the partition boundary to match. Do it the other way — pull the partition's end marker inward while the filesystem still believes it owns the full range — and the filesystem will happily read and write past the new boundary into space that is no longer reserved for it. That is instant, irreversible corruption. The shrink direction is unforgiving: filesystem first, always, and take a backup before you start. (XFS, worth knowing, cannot shrink at all — only grow.)

This foot-gun is the best argument for LVM there is. With LVM the resize is one command that handles both layers in the correct order for you, online, with no chance of crossing the streams. Which brings us to the recommendation the whole page has been circling.

How to Lay Out a Server — The Opinionated Version

You now know enough to do this well, so here's the prescriptive guidance, the part most tutorials leave to "it depends."

Use GPT. On anything modern, there is no reason to choose MBR. It buys you nothing and costs you the future.
Let the installer's 1 MiB alignment stand. Don't outsmart it. The default is correct; deviating from it only introduces the read-modify-write penalty you just learned to avoid.
Think hard before carving many fixed partitions. The instinct from the desktop world — a partition for /, one for /var, one for /home, one for /tmp — gives you isolation, but it also locks each size in concrete on day one, and day one is exactly when you know the least about how the server will actually be used. The moment /var fills while /home sits empty, you're stuck.
Reach for LVM when you want flexibility. A modern, low-stress layout is small and boring: an EFI System Partition, maybe a small /boot, and then one big partition handed entirely to LVM. Slice logical volumes out of that pool as you need them, grow them online when they fill, snapshot them before a risky upgrade. You keep the isolation benefit of separate volumes without nailing the sizes down forever. For most servers, this is the right default — fixed partitions are for the boot-critical bits that have to exist before LVM does.

The through-line: partitions are the right tool for the handful of regions that must be simple and self-contained (the boot chain), and LVM is the right tool for everything that should be able to flex. Match the tool to whether the size is ever going to change.

Gotchas

The traps, roughly in order of how often they bite:

/dev/sda ≠ /dev/sda1. Formatting the disk wipes the table and every partition; formatting the partition touches only that slice. The most expensive typo in storage. Re-read the device-name section if it isn't reflexive yet.
Device names reshuffle at boot. /dev/sda is not guaranteed to be the same disk tomorrow. Use UUIDs in /etc/fstab and confirm with lsblk before any destructive command.
Shrink the filesystem before the partition. Reverse the order and you corrupt the filesystem instantly. Worth saying twice, which is why it has a Danger box above.
The kernel may not see your new partition. After editing the table on a disk with mounted partitions, the running kernel sometimes keeps the old map. Run partprobe /dev/sda (or partx -u) to make it re-read the table, instead of being baffled that your shiny new /dev/sda4 doesn't exist yet.
A whole-disk filesystem confuses the unwary. If mkfs was run on /dev/sdb directly, there's no partition table — fdisk -l /dev/sdb shows nothing useful and you might think the disk is blank. Check lsblk -f or blkid; the filesystem is sitting right there on the bare device, exactly as designed.
MBR's 2 TiB ceiling fails silently. Partition a 4 TB disk with MBR and the back half doesn't error — it just isn't addressable. If a big disk looks suspiciously like a 2 TB disk, check the table format with fdisk -l.

History and Philosophy

Partitioning is almost as old as the personal computer. The Master Boot Record arrived with IBM's PC DOS in 1983, solving a real problem of the day — let one physical disk host more than one operating system — with the resources of the day: a single 512-byte sector at the very front of the disk, holding both the boot code and a four-entry table. It was a fine design for a 10-megabyte drive. Its sins were all the sins of success: it lived far longer than anyone imagined, and every limit that felt absurdly generous in 1983 became a wall as disks grew a hundred-thousand-fold.

The extended-partition hack — one primary repurposed as a container for a chain of logical partitions — is a little monument to that longevity, a workaround that outlived the problem it patched. By the late 1990s the cracks were structural, and Intel's UEFI initiative replaced the lot with GPT: a table with room to breathe, a backup copy so a single bad sector couldn't orphan a disk, and 64-bit addressing that won't need replacing in any of our lifetimes. The transition took the better part of two decades, the way these things do, but it's effectively complete now — a new server with an MBR disk is a curiosity.

The deeper idea underneath all of it has barely changed since 1983, though, and it's worth pausing on: a partition is just a promise. The disk doesn't enforce the boundaries; nothing physically stops a filesystem from reading past its partition's edge — which is precisely why the shrink foot-gun is so dangerous. The whole edifice of partitions, types, and flags is a shared agreement among the firmware, the kernel, and the tools to respect a few numbers written in a table near the front of the disk. It works not because it's enforced but because everyone agreed to read the same map. There's something fitting in that — the foundation of every server's storage is, at bottom, a polite convention everyone chooses to honor.