How to Partition Your Disks

12 min read

#Linux #Arch #Storage

Part 3 of 6 in Running Linux, My Way

Installing Arch the way you want it starts with deciding how to split up the disk. This post covers the basics behind that decision: what a disk and a file system actually do, why partitions exist at all, the partition types you actually need, how multi-boot changes the calculus, and an actual partition schema that’s held up for years.

What’s a Disk, and What Does a File System Do #

What’s a Disk #

Before talking about partitions, let’s talk about disks. A disk is a physical piece of hardware attached to your machine that stores an array of ones and zeros. It comes in a type, SSD, HDD, flash, and so on, and a size, 1GB, 500GB, 1TB, whatever. That raw array of bits is fine for storage, but it’s useless on its own, we need some abstraction on top of it.

What’s a File #

The first layer of that abstraction is the file itself. A disk on its own doesn’t know about files, it just knows about bytes at some offset. A file is what turns a chunk of those bytes into something you can actually work with: it has a name, a size, permissions saying who can read or write it, timestamps for when it was created or last touched. Instead of remembering “my data starts at byte 4,204,928 and runs for 12KB”, you just open my_document.txt. That’s the whole point of the abstraction, you get to think in terms of files instead of raw offsets on a disk.

What a File System Actually Does #

When you want to store something on disk, you create a file. But where does that file actually go? At the start of the disk? The end? Somewhere in the middle? Who decides? That’s the job of the file system driver, ext4, NTFS, FAT, and so on. It’s not as simple as it sounds. The naive approach is to just append every new file to the end of the disk, and that works fine right up until you delete one. Now there’s a hole in the middle, and if the next file you write isn’t exactly the size of the one you deleted, you’ve either wasted space or you need something smarter to fill the gap. There’s a lot more to file systems than this, but that’s not what this post is about. What matters here is: disks store bytes, and file systems decide where those bytes actually live.

Kinds of Files: User, System, and Temp #

Files on a system fall into a few different buckets. There are your files: photos from an image editor, a movie you downloaded, a text file you wrote. The OS doesn’t care about these, they only matter to you. Then there are the system’s files: a program is also just an array of ones and zeros stored on disk, and so is the kernel, and so is every system configuration file. And there’s a third bucket that’s easy to forget: temp files, things you only need for a few minutes or a few days and don’t actually care about keeping around.

You don’t want these three categories mixed together on disk. If you ever need to wipe every system file during a reinstall, you don’t want to risk touching your own documents. If you want to back up your own files, you don’t want to waste space backing up the OS along with them. And temp files should be safe to nuke at any point without a second thought. Keeping them apart, physically, is exactly what partitions are for.

What’s a Partition, and Why Bother #

A partition is a physical region inside a disk that holds files. When a file system writes a file, it isn’t writing to the disk as a whole, it’s writing into a partition inside that disk. Splitting a disk into partitions is how you keep user files, system files, and temp files from ending up mixed together in the same pool.

Partitions aren’t very flexible once there’s real data on them. Resizing one after the fact is possible, but it’s not something you want to do casually, shrinking and growing partitions with live data on them is asking for trouble. That means the right time to think hard about your partition layout, how many you need and how big each one should be, is before you install anything, not after.

Partitions Using the Old MBR #

For a long time, partition tables lived in the MBR, the Master Boot Record: a single 512-byte sector at the very start of the disk, mostly bootstrap code, with just 64 bytes left for the partition table itself. Split into 16-byte entries, that’s exactly 4 partitions, no more.

MBR also tops out at 2TB per disk, and the whole partition table lives in that one sector with no backup and no checksum, corrupt it and the whole partition map goes with it. It’s what BIOS systems booted from for decades, and there’s no good reason to reach for it today unless you’re stuck with genuinely old hardware.

MBR packs the boot code and a 4-slot partition table into one 512-byte sectorSector 0 breaks into 446 bytes of bootstrap code, a 64-byte partition table, and a 2-byte signature. The 64-byte table splits into exactly 4 sixteen-byte entries, a hard limit on how many partitions MBR can describe.sector 0, all 512 bytes of itbootstrap code (446 bytes)partition table(64 bytes)sigthe 64-byte table, exactly 4 entries of 16 bytes eachentry 1entry 2entry 3entry 4
MBR crams the boot code and a 4-slot partition table into a single 512-byte sector at the start of the disk.

Partitions Using the New GPT #

GPT, the GUID Partition Table, replaced MBR and fixes each of those problems. Its table has room for 128 partitions by default, no hack required, and every partition gets a real type GUID, EFI system, Linux root, swap, and so on, instead of MBR’s vague type byte. The 2TB ceiling is gone too, thanks to 64-bit addressing.

The bigger win is resilience: GPT keeps a full backup of the partition table at the very end of the disk, checksummed, so a corrupted primary table can be recovered instead of taking the whole disk down with it. GPT is also what UEFI expects to boot from, which is exactly why the EFI partition below matters. Unless there’s a specific reason not to, GPT is the schema to use.

GPT keeps a full partition table near the start of the disk and mirrors it at the endLeft to right: a protective MBR, the primary GPT header and its table of up to 128 partitions, then the actual partitions, then a backup partition table and backup header at the very end of the disk, mirroring the primary copy.the whole disk, start to endprotectiveMBRprimary GPTheaderpartition table(up to 128 entries)EFI, /boot, root, home, swap...the actual partitionsbackuptablebackupheaderbackup mirrors the primary, so one bad sector doesn't take out the whole tablestart of diskend of disk
GPT keeps a full partition table near the start of the disk plus a backup copy at the end, with room for 128 partitions instead of 4.

Partition Types You Actually Need #

Once you’ve decided you want partitions, the next question is which ones. A few types show up in basically every real layout:

Multi-Boot and the Boot Chain #

None of this matters much if you’re only ever running one OS. In a single-OS system, /boot living inside that OS’s own root partition is fine, there’s only one owner, so tying boot config to root causes no problems. Run Windows and multiple Linux distros side by side, though, and that assumption breaks.

GRUB is one program, but it’s shared across every OS on the disk. UEFI firmware only boots one .efi binary per NVRAM entry, so that one GRUB instance has to know about every kernel on the disk. Its menu isn’t “Arch’s menu” or “Debian’s menu”, it’s the whole system’s menu, so its config can’t belong to any single OS’s root partition either.

The right way to handle this is a dedicated /boot partition, one that’s shared across every OS on the disk instead of owned by any single one of them. It needs to be writable by, and mounted at the same path from, every OS on the disk, so any distro’s kernel-update hook writes to the one real config. And it needs to survive any single OS’s root filesystem dying, since none of them are supposed to be able to take the shared boot menu down with them.

So why not just use the EFI partition for this too? It’s already sitting at the start of the disk with that 512MB reserved for UEFI, already shared by every OS, exactly the properties just described. It’s possible, nothing stops you, but it’s not recommended. Mixing a dedicated FAT32 firmware partition with GRUB’s own config just doesn’t sit right, and I like things clean.

Put simply, the whole chain looks like this: firmware hands off to the EFI partition, the EFI partition hands off to GRUB, and GRUB hands off to whichever OS you picked. Three separate handoffs, three separate partitions, each with its own job.

Without a dedicated /boot partition, one OS accidentally owns the shared GRUB menuLeft panel: no dedicated /boot, grub.cfg lives inside one OS's own root partition, so if that OS breaks, the shared boot menu breaks too and the other OSes become unreachable. Right panel: a dedicated /boot partition holds grub.cfg independently, so every OS can write to it and none of them owns it, one OS breaking has no effect on booting the others.no dedicated /bootdedicated /boot partitionOS Agrub.cfg lives hereOS BOS COS A breaks → shared menu breaks → OS B and C unreachable/boot (shared)OS AOS BOS Cevery OS can write here, none of them owns it
Without a dedicated /boot partition, whichever distro you ran grub-install from accidentally owns the shared menu, and takes it down with it if it breaks.

My Own Schema #

I had this partition schema long before I switched to Arch. It just made sense to take a 2TB SSD and split it up deliberately, especially since shrinking and growing partitions later is a nightmare.

A couple of things need reserving up front: UEFI wants that 512MB partition at the very start of the disk, and I reserve a swap partition right after it, sized to match my physical RAM, 32GB of RAM, 32GB of swap.

There are plenty of recommended partition schemas floating around, here’s how I actually split my 2TB SSD:

A 2TB disk split into a small boot sliver, half for user files, a Windows install, and eight flexible 100GB chunksTop bar shows the whole 2TB disk to scale: a thin EFI and swap sliver, 1TB for user files, 200GB for Windows, and 800GB left flexible. That flexible 800GB zooms into a bottom row of eight equal 100GB partitions: Arch1, Arch2, Debian, LFS, var, temp, and two spares.the whole 2TB disk, drawn to scale1TB, my own files200GBWindows800GB, flexibleEFI + swapsplit into eight equal 100GB partitionsArch1Arch2DebianLFS/vartempsparespare
1TB for my own files, 200GB for Windows, and the remaining 800GB split into eight equal 100GB partitions I can commit to whatever I want.

I’ve never fully committed any of those 8 partitions to a single purpose. Having 100GB chunks sitting around means I can always decide to try another distro, or carve one off for something new, without having to touch anything else. And 1TB for my own files is more than I’ve ever come close to using.

Arch1 and Arch2 exist purely out of caution. Before I installed Arch the first time, I kept hearing that a random pacman -Syu could break the system out from under you. So I set up two identical root partitions and switched between them with GRUB: if one broke, I still had the other to use until I had time to fix it. Needless to say, Arch has never actually broken on me in over 5 years, not once has a pacman -Syu forced me onto the backup. But I still keep both, just in case.

Picking a Boot Loader #

None of this works without a boot loader that can juggle multiple OSes on multiple partitions. I want Windows and several distros all available to me, so GRUB was the obvious choice, it’s built for exactly this. I’ll get into how I actually configure it, including keeping its config under version control, in a later post.

Plan Before You Install #

Having a real partition plan before you even open an Arch installation guide is, in my opinion, mandatory. Do this before you install any OS. It’s not easy to redo on a disk that already has data on it, but at least now you know what to aim for, and you can get there next time you get a new disk, or if you’re willing to play the shrink-and-grow game on the one you’ve got.