Stop making swap partitions

swap.md

Stop making swap partitions—use swap files instead!

Swap files have had the same performance characteristics as swap partitions for more than 20 years and yet, linux distributions continue to encourage the use of swap partitions during install.

Swap files are easier to use/add/remove/modify/extend after installation. They're better in every way––use swap files!

1. Create and format the swap file.

mkswap --size 4G --file /swapfile

Tip

--file requires util-linux 2.40 or newer. mkswap creates the file, sets mode 0600, preallocates the blocks (ftruncate + posix_fallocate), and, since 2.41, sets the nocow attribute so this also works on Btrfs. Thank @cesarb from HN for the tip!

2. Enable it.

swapon /swapfile

3. Make it persist across boots.

echo "/swapfile none swap defaults 0 0" >> /etc/fstab

probably add setup for /etc files for starting system

It's sad that swap on ZFS is still unsupported and leads to system freeze/crash under high memory load.

... for more than 20 years

My built-in Devil's Advocate has to ask if that's really "for more than 20 years" or "was the case 20 years ago" (two entirely different things)? Have you got a citation newer than 2 decades old? Frankly, i find it difficult to believe that anything living in a filesystem can be faster than something living outside of one, for the simple reason that abstraction penalties are real and an FS inherently includes one.

Edit: in 30 years of administering Linux and (previously) Solaris sytems i've never once had to resize a swap partition after system installation, so claims of administrative overhead/headaches are, i opine, exaggerated. i'll also claim that keeping swap out of the filesystem is better hygiene, e.g. they don't need to be explicitly excluded from backups or arbitrary rsync invocations.

i'll also claim that keeping swap out of the filesystem is better hygiene, e.g. they don't need to be explicitly excluded from backups or arbitrary rsync invocations

This guy sysadmins

As long as you're okay with swap becoming available after your filesystems do - there are cases where you might not want that though. Memory-constrained systems with CoW FSes that eat RAM are the first place that comes to mind - basically anywhere that there's a reasonable possibility of OOM before the full system comes up.

As well, in FreeBSD, our swap partitions serve double-duty as kernel dump devices - and if you get a panic before all of ZFS comes up for example, there's nowhere to store it.

You can also just leave a swap partition alone when reinstalling the OS. I have a smaller SSD that contains the swap partition alongside a generic "DMZ" EXT4 partition for temporary use.

And df won't misreport an extra 20-30 GB.

It's sad that swap on ZFS is still unsupported and leads to system freeze/crash under high memory load.

On any system running ZFS it's almost certainly going to be a large consumer of RAM for the ARC, and it's possible to get into situations where ZFS's own pages end up swapped to a ZFS-backed file/zvol and there are some wild recursive contention/runaway scenarios. With some serious sysctl tuning this is possible to guard against, however trying to do this on a default system will almost certainly end up in the sort of scenario you alluded to.

Source: I am a FreeBSD committer and ZFS contributor

... for more than 20 years

My built-in Devil's Advocate has to ask if that's really "for more than 20 years" or "was the case 20 years ago" (two entirely different things)? Have you got a citation newer than 2 decades old? Frankly, i find it difficult to believe that anything living in a filesystem can be faster than something living outside of one, for the simple reason that abstraction penalties are real and an FS inherently includes one.

It was introduced in June 2002… so 24 years ago to be precise 😃. See also, email discussion linked in the op (we didn’t have git back then). This code path is very stable. See specifically the comments: https://github.com/torvalds/linux/blob/827751b699b79a6e569983359c02dce67f81b94c/include/linux/swap.h#L183

and

https://github.com/torvalds/linux/blob/827751b699b79a6e569983359c02dce67f81b94c/mm/swapfile.c#L2934

My first recommendation is just to avoid swap all together and right-size your hardware to your workload while runningvm.swappiness=0. For availability, deterministic behavior is better.

There are fringe pathological cases where a small amount of swap in RAM (yes, I know) are the best prescription to work around presumptuous code paths but you’ll know if this is you.

Back in the day, we used to put the swap partition between / and /var so that you'd be more likely to have the disk head nearby when needed to get a little bit of a latency improvement. I've been a swap files convert for a long time, though; the flexibility in disk arrangement helps in strange situations. Obviously, embedded and other situations will need their own recipes - but that's why we love Linux, it lets us make the choice.

Great advice for servers. I wouldn't recommend a swapfile on hosts which are expected to hibernate to swap. If your distro doesn't tack on the necessary resume_offset to the kernel's boot parameters, resume may never work.

dont try this on zfs!