Appendix C

Partitioning
your disk.

Partitioning is the first real decision the installer asks you to make, before you've even seen a desktop. One big partition, or several smaller ones? Swap partition or swap file? How much space for root versus home? This page answers all of it — including when the right answer is "just use one partition."

Appendix C
Before you install
Desktop + server coverage

Section 01

What partitioning actually does.

A partition is a defined region of a storage device. The disk doesn't know or care what's in each region — partitioning is just the act of drawing lines on the disk and assigning each region a filesystem and a purpose.

On Linux, each partition can be mounted at a path in the filesystem tree. Mount /dev/sda2 at /home and everything written to /home goes to that partition — physically separate from / even though it looks like one unified directory tree.

Before you can create partitions, the disk needs a partition table — a small data structure at the very beginning of the disk that describes where the partitions are. Two formats matter:

MBR (Master Boot Record) — the old format. Supports disks up to 2TB. Maximum 4 primary partitions (workaround: extended/logical partitions). Required for legacy BIOS boot on very old hardware. If you're installing on a machine from the last decade, you almost certainly don't need this.

GPT (GUID Partition Table) — the modern format. Supports disks up to 9.4 ZB. Up to 128 partitions. Required for UEFI boot. Stores partition data redundantly (at start and end of disk). If you're on any remotely modern machine (post-2012ish), use GPT. The Debian installer defaults to it when it detects UEFI firmware.

ext4 — the default for most Linux installs. Mature, stable, fast, well-understood. If nothing else in this list means anything to you, use ext4 and move on. It handles everything a desktop user needs.

btrfs — a copy-on-write filesystem with built-in snapshot and subvolume support. Fedora defaults to it. Useful if you want rollback capability (snapshot before an update, roll back if it breaks). More complex than ext4; recovery when it goes wrong is harder.

xfs — high-performance filesystem, excellent for large files and high-throughput workloads. Common on servers and NAS. Cannot shrink in place (you can grow it, but not shrink). Good choice for /var or data partitions on servers.

FAT32 — required for the EFI system partition. Not a choice, a requirement. The UEFI firmware itself reads the ESP and it only understands FAT32.

Section 02

The honest case for one big partition.

The argument for splitting your disk into many partitions sounds compelling until you realize the most common result is that one partition fills up while another sits mostly empty. Disk space is fungible. Partitions are not.

Scheme A — Minimal (desktop, single user, EFI system)
/boot/efi 512 MB
/ (root) everything else
EFI System Partition — FAT32, required on UEFI
Root — ext4, contains everything else including /home

Swap in this scheme is a file inside / — not a partition. See Section 04. This is now the preferred approach on modern systems.

This scheme is completely valid for a single-user desktop or laptop where you're the only person who uses the machine, you're not running services that generate significant log volume, and you don't need to reinstall the OS while preserving your data. The EFI partition is mandatory on UEFI systems — that's not a choice. Everything else can live in root.

The trade-off is recovery friction: if you want to reinstall the OS, your home directory and OS files are on the same partition, so you'd need to back up /home externally before wiping. If you do this often enough, a separate /home partition pays for itself immediately.

Section 03

The practical desktop scheme.

Adding a separate /home partition is the single most useful thing you can do beyond the minimal scheme. It is also the only partition split that most desktop users will ever actually benefit from.

Scheme B — Desktop recommended (separate /home)
/boot/efi 512 MB
/ (root) 40–60 GB
/home rest of disk
EFI System Partition — 512 MB, FAT32
Root — 40–60 GB, ext4
Home — remainder, ext4

Why separate /home? Your home directory contains your config files (dotfiles), documents, downloads, music, and everything personal. The OS in / is replaceable. When you separate them onto different partitions, you can wipe and reinstall / — even switch distros — without touching /home at all. Just tell the new installer to mount the existing partition at /home without formatting it.

In / (root)

  • /bin, /sbin, /lib — system binaries
  • /usr — installed applications
  • /etc — system config files
  • /boot — kernel and bootloader
  • /var — logs, package cache, databases
  • /tmp — temporary files
  • /root — root user's home

In /home

  • ~/ — your home directory
  • ~/.config — application config
  • ~/.local — user-installed data
  • ~/.fluxbox, ~/.bashrc — dotfiles
  • ~/Documents, ~/Downloads
  • ~/Music, ~/Pictures, ~/Videos

/boot holds your kernel images, initramfs, and bootloader configuration. In most modern setups with UEFI and GPT, a separate /boot partition is not needed — the kernel lives in /boot inside root, and the EFI partition handles the bootloader separately.

You need a separate /boot partition in two specific cases:

  • Full-disk encryption (LUKS) — the bootloader can't read an encrypted partition to find the kernel. A small unencrypted /boot (512 MB–1 GB) holds the kernel in the clear, and the encrypted root partition mounts after you enter your passphrase at boot.
  • Root on LVM — same issue: GRUB can't read LVM without help. A plain /boot outside LVM solves it.

Standard desktop install with no encryption or LVM: leave /boot inside root. The Debian installer handles this correctly by default.

Server scheme — for completeness

If you're building a server, two more separations become meaningful. On a desktop, these almost never matter.

Scheme C — Server (protect root from service-generated growth)
/boot/efi 512 MB
/boot 1 GB
/ 20 GB
/var 20–40 GB
/home remainder
swap 8–16 GB
EFI — 512 MB
/boot — 1 GB (outside LUKS if encrypted)
/ — 20 GB min
/var — logs, package cache, databases
/home — user data
swap — partition or file

Why /var on a server? /var is where logs grow, package caches accumulate, databases write their files, and mail spools. On a server running services, an uncontrolled log flood or a large database dump can fill /var to 100%. If /var shares root, a full /var crashes the OS — you can't log in, can't write anything, system is dead. Separate /var means that runaway log growth fills the /var partition while the OS continues running. You get an alert, you fix it, nothing else breaks.

Section 04

Swap: partition or file?

Swap is overflow space on disk for when RAM fills up. The kernel can move memory pages that haven't been accessed recently from RAM to swap, freeing up RAM for active processes. It also stores a complete RAM snapshot to disk when the system hibernates.

Swap used to always be a dedicated partition. Modern Linux supports swap files — regular files inside an existing filesystem that behave identically. The question is whether there's any real reason to prefer one over the other.

Swap file
Setup
Easier. Create with fallocate, format, add to /etc/fstab. No repartitioning.
Resize
Easy. Disable, delete, create a new file at a different size, re-enable. No partition editor needed.
Performance (SSD)
Identical. File overhead is negligible on SSDs. Not distinguishable in practice.
Performance (HDD)
Slightly slower. File fragmentation can cause non-contiguous writes. Partition is always contiguous. The gap is small.
Hibernation
Extra setup. Requires resume=UUID and resume_offset kernel parameters. Not impossible, just more steps.
Filesystem constraint
Some limits. Cannot live on btrfs without extra configuration (use a subvolume with CoW disabled). Fine on ext4 and xfs.
Flexibility
High. Can be disabled and removed entirely without touching the partition table. Useful if you find you never use swap.
Swap partition
Setup
Requires planning. Must be allocated at install time. Changing size later means repartitioning, which risks data.
Resize
Hard. Requires a live environment, partition editor, moving adjacent partitions. Risky without a backup.
Performance (SSD)
Identical. No practical difference versus a swap file on SSD hardware.
Performance (HDD)
Marginally faster. Dedicated contiguous region with no filesystem layer. Advantage is real but usually not noticeable.
Hibernation
Simpler. Kernel just needs resume=UUID pointing at the partition. One parameter, no offset calculation.
Filesystem constraint
None. Swap partition has no filesystem. Works regardless of what filesystem the rest of the disk uses.
Flexibility
Low. Space is permanently committed to swap even if you never use it. Can't reclaim it without repartitioning.

Recommendation: use a swap file. The flexibility wins on a desktop. You can resize it without touching the partition table, disable it if you find you don't need it, and the performance difference on an SSD is genuinely zero. If you need hibernation, the extra kernel parameters are a one-time setup. The only reason to prefer a swap partition is if you're on spinning disk hardware and want to squeeze every millisecond of swap performance, or if you're running btrfs and want to avoid the CoW configuration step.

Creating a swap file

# Create an 8GB swap file
sudo fallocate -l 8G /swapfile

# Lock down permissions — only root should read swap (it can contain memory contents)
sudo chmod 600 /swapfile

# Format it as swap
sudo mkswap /swapfile

# Enable it immediately (without rebooting)
sudo swapon /swapfile

# Make it persist across reboots — add this line to /etc/fstab:
/swapfile none swap sw 0 0

# Verify it's active
swapon --show
free -h # Swap row should now show size

The old rule was "2× your RAM." That came from an era when RAM was measured in megabytes and the kernel's memory management was less sophisticated. It's not a useful rule on modern hardware.

What actually matters:

  • No hibernation: Swap is just an OOM buffer. 4–8 GB is sufficient for most desktops. If you have 16 GB or more of RAM, you may never touch swap at all — but having some is still good practice for edge cases.
  • With hibernation: Swap must be at least as large as your installed RAM. When you hibernate, the kernel dumps the entire contents of RAM to swap. 16 GB RAM = 16 GB minimum swap. Practically, match or slightly exceed RAM.
  • With zRAM (see below): You may want minimal or no disk swap at all. zRAM handles memory pressure in-RAM with compression.

zRAM creates a compressed block device entirely in RAM and uses it as swap. When memory pressure is high, the kernel compresses less-used pages and moves them to the zRAM device — freeing real RAM, without writing to disk at all. Access time is RAM speed, not disk speed.

Fedora, Chrome OS, and Android all default to zRAM. On a modern desktop with plenty of RAM (16 GB+), zRAM often eliminates the need for any disk swap. The trade-off: zRAM can't save state for hibernation, so you still need disk swap if you hibernate.

# Install and enable zRAM on Debian
sudo apt install zram-tools
sudo systemctl enable --now zramswap

# Verify
zramctl

The vm.swappiness kernel parameter (0–200) controls how eagerly the kernel moves memory pages to swap. Default is 60. Lower values make the kernel prefer keeping things in RAM; higher values make it swap more freely.

For a desktop with an SSD and plenty of RAM, a lower value (10–30) often feels snappier because programs don't get paged out while you're actively using them. For a server, the default or higher values are usually better — the kernel is smarter than you about what's hot and cold.

# Check current swappiness
cat /proc/sys/vm/swappiness

# Set temporarily (resets on reboot)
sudo sysctl vm.swappiness=10

# Set permanently — add to /etc/sysctl.d/99-swappiness.conf:
vm.swappiness = 10

SSDs have a finite write endurance, measured in TBW — terabytes written. Every NAND flash cell can only be programmed and erased a limited number of times before it stops reliably holding data. Consumer SSDs are rated anywhere from 75 TBW (cheap 256 GB drive) to 600+ TBW (high-endurance 1 TB drive). Writes to swap count toward that total.

The concern: a high swappiness value on a system that regularly hits memory pressure means the kernel is constantly writing memory pages to the SSD and reading them back. Each cycle burns write endurance. On a spinning hard disk this doesn't matter — mechanical platters don't wear out from writes. On flash storage, they do.

How serious is the risk? For most desktop users: real but overstated. A typical desktop that never runs out of RAM will barely touch swap regardless of swappiness setting, writing a few gigabytes to swap per year at most. A 300 TBW drive at that rate lasts decades. The concern becomes real if your machine regularly exhausts physical RAM — a laptop with 8 GB running a browser, Electron apps, and a VM simultaneously, for example. In that scenario, high swappiness with swap on SSD is genuinely eating drive life every session.

The write amplification problem

SSDs don't overwrite individual bytes — they erase and rewrite entire blocks (typically 128 KB–4 MB). If the kernel writes one 4 KB memory page to swap, the SSD controller may need to erase and rewrite a full 128 KB block to accommodate it. This amplification means actual flash writes are larger than the data writes you initiated. Modern SSDs have wear-leveling controllers that distribute writes across cells to even out the wear, but amplification is always a factor.

You can see how much your drive has actually written versus what the OS requested with smartctl:

sudo apt install smartmontools
sudo smartctl -a /dev/nvme0 # NVMe SSD
sudo smartctl -a /dev/sda # SATA SSD
# Look for: Data Units Written (NVMe) or Total_LBAs_Written (SATA)
# Compare to your drive's TBW rating in its datasheet

The practical mitigations, in order of impact:

  1. Use zRAM instead of disk swap. Compressed swap in RAM. Zero disk writes. The right answer for any system where memory pressure is a concern and you don't need hibernation. See the zRAM section above.
  2. Lower swappiness to 10. The default of 60 means the kernel will happily push memory to swap well before RAM is actually full. At 10, it only swaps under real pressure. This is the single-line config change with the biggest impact on SSD wear for typical desktop use.
  3. Add more RAM. A system that never exhausts physical RAM never writes to swap. Going from 8 GB to 16 GB costs less than a new SSD and eliminates the problem entirely for most workloads.
  4. Use a high-endurance SSD for swap. If you need swap on SSD and can't use zRAM (e.g., hibernation), buy a drive with a high TBW rating. An SSD rated for 600 TBW with a low-swappiness desktop workload will outlast the computer it's in.

The setup to avoid: High swappiness (60+) + swap on a budget SSD (low TBW) + regular memory pressure (system frequently near RAM limit). That combination genuinely shortens drive life. Any one of the three factors alone is manageable. All three together is the problem.

Section 05

Every mount point — what it holds and when to separate it.

This is the full reference. Most of these you will never need to separate on a desktop. Read the "who needs this separate" column honestly.

/boot/efi Always separate
EFI System Partition
Required on any UEFI system. The firmware reads this partition directly to find the bootloader. Must be FAT32 — the firmware doesn't understand Linux filesystems. Contains the GRUB EFI binary and boot entries. Cannot be inside root or on any other filesystem.
512 MB. 100 MB is the minimum; 512 MB gives room for multiple boot entries (dual boot, multiple kernels). 1 GB if you plan to maintain many kernels simultaneously.
/ Always exists
Root — everything that isn't elsewhere
The top of the filesystem tree. All other mount points are branches off this. Contains the OS, installed software, configuration, and anything not on a separate partition. If you're running a single-partition setup, everything is here.
25–60 GB for a desktop. The OS itself is 5–10 GB. Software adds up — a full install with a browser, office suite, and some dev tools can be 15–20 GB. Give it room to grow. 40 GB is a safe default.
/home Recommended desktop
User home directories
Your documents, dotfiles, downloads, and personal config. Separating it lets you reinstall or switch the OS without losing your data. On a multi-user machine, it also prevents one user's data from consuming space that the OS needs.
Everything left after root and swap. On a 500 GB drive with a 40 GB root, that's ~450 GB for home. There's no upper limit that makes sense to set — give it what you can.
/boot Only if needed
Kernel images, initramfs, GRUB config
Needed outside the encrypted partition in a LUKS full-disk encryption setup, or when root is on LVM. On a standard unencrypted desktop with UEFI, /boot inside root is completely fine — the Debian installer puts it there by default.
512 MB–1 GB. Kernels are 10–30 MB each; Debian keeps two or three installed at a time. 512 MB is enough. 1 GB gives comfortable headroom.
/var Server use
Variable data: logs, caches, databases, mail, print spool
On a server, /var/log can grow without bound from service logs, /var/lib holds database files, and /var/cache/apt accumulates package downloads. A separate partition means runaway growth here can't take down the OS. On a desktop, log growth is minimal and this separation usually just wastes space.
10–40 GB depending on services. A database server may need 100 GB+. A web server with moderate logging: 20 GB. Monitor usage with du -sh /var/* on a running system before deciding.
/tmp Usually tmpfs
Temporary files — cleared on reboot
Modern systemd systems mount /tmp as tmpfs by default — a RAM-backed filesystem that exists only in memory and disappears on reboot. This is faster than disk and requires no partition. A separate disk partition for /tmp is only useful if you need to limit the size of temporary files (e.g., a build server where compilations generate multi-GB temp files).
tmpfs uses RAM, not disk. Default is capped at half of RAM. Separate disk partition: 5–20 GB depending on workload. Check with findmnt /tmp — if it says tmpfs, no disk partition is needed.
/usr Don't separate
User-space programs and libraries
/usr holds everything in /usr/bin, /usr/lib, and /usr/share — essentially all installed software. Separating it made sense decades ago when /usr might live on a network share. Today, the kernel and initramfs expect /usr to be available immediately at boot; a separate partition adds complexity with no practical benefit on modern systems. Leave it inside root.
Leave inside /.
/opt Rarely separate
Optional, self-contained third-party software
Some proprietary software (Oracle, some enterprise tools) installs into /opt to stay self-contained and avoid conflicts with the distro's package manager. On a desktop, almost nothing uses /opt except maybe a few Flatpaks or snap-equivalent tools. Separating it is rarely worth the partition slot.
Leave inside / unless you have a specific enterprise application requirement.

Section 06

Size guidelines at a glance.

These are practical recommendations, not rules. Your actual usage will vary — the right move after installing is to monitor with df -h and adjust future installs based on what you actually consumed.

Desktop / laptop (scheme B, 500 GB SSD)

Mount point Recommended size Filesystem Notes
/boot/efi 512 MB FAT32 (required) First partition. Non-negotiable on UEFI.
/ 40–60 GB ext4 OS + all installed software. 40 GB is safe; 60 GB if you install a lot.
/home remainder ext4 Give it everything that's left. Don't try to predict how much you'll need.
swap 8–16 GB (file) swapfile inside / RAM size if you hibernate; 8 GB otherwise. Created after install, not during.

Server (scheme C, 1 TB drive)

Mount point Recommended size Filesystem Notes
/boot/efi 512 MB FAT32 Same as desktop.
/boot 1 GB ext4 Outside LUKS if encrypted. Holds kernel and initramfs only.
/ 20–30 GB ext4 Smaller than desktop — no desktop apps, no media. Just OS and system software.
/var 20–100 GB ext4 or xfs Size based on services. Monitor du -sh /var/* after a week of operation.
/home remainder ext4 Or a dedicated data volume depending on workload.
swap RAM size partition or file Servers may need hibernation during maintenance windows. Partition is simpler here.

Checking your usage after install

The most useful tool for understanding partition usage over time:

# All mounted filesystems, human-readable sizes
df -h

# Top space consumers in /var (useful for servers)
du -sh /var/* | sort -rh | head -10

# Top space consumers in /home
du -sh /home/*/ | sort -rh

# What's using space in the current directory, depth 1
du -h --max-depth=1 . | sort -rh

Root is too small: You'll see warnings when packages can't install. Solutions: move large directories (/var/cache, /opt) to a different mount; use ncdu to find and purge large files; resize the partition with gparted from a live USB (extend root, shrink home). ext4 supports live resizing in some directions.

Home is too small: Move it. On a separate partition: back up, resize, restore. If /home is inside root and root has room: nothing to do. If /home is on its own partition and is full: external drive + resize from live USB.

Swap is too small: If you used a swapfile, disable it (sudo swapoff /swapfile), delete it, create a larger one, re-enable. Five minutes. If you used a partition, you need a live environment and a partition editor. This is the main practical reason to use a swapfile.