Swap files have matched swap partitions for 20 years—so why do Linux installers still push partitions?

Stop making swap partitions–use swap files instead

Swap files have performed identically to swap partitions for over two decades, yet Linux distributions keep steering users toward dedicated partitions during installation. Swap files win on every practical front: they're easier to add, remove, modify, and extend after the fact. The gist walks through the whole setup—creating the file with fallocate, locking down permissions, running mkswap and swapon, and making it persist in /etc/fstab—plus a btrfs-specific one-liner.

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.
  1. ghostly_s

    I'll continue listening to my OS vendor rather than this random github user with some broken links, thanks.

    (I’m not interested in being educated on this, I have better things to do. Bring it up with Debian.)

  2. rini17

    Use zram instead. This from crappy 8G RAM multimedia/browsing minipc I'm on right now. The SSD is quite slow and browser is memory hungry so it was an improvement from on disk swap.

    $ zramctl

    NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT

    /dev/zram0 zstd 3G 482.9M 86.7M 91.8M 4 [SWAP]

  3. cesarb

    > fallocate / chmod / mkswap

    Why not "mkswap --size ... --file ...", which does these three things and more? For instance, according to the mkswap man page, "[...] sets the nocow attribute for newly created files [...]" which is a detail that seems to be missing from this gist.

  4. SoftTalker

    For a while since RAM sizes have gotten so big I would set up linux servers without swap at all. I figured what is a 2GB swap file going to do if the system has already exhausted 128GB of real RAM?

    I never saw any issues doing this, but I learned that linux ideally wants some swap space, which it will use for some kind of housekeeping stuff.

  5. kazinator

    Swap partitions are your set-and-forget permanent installation that covers daily use.

    Swap files are for "oh shit, I need to run this rare thing that needs lots of VM". You create them, "swapon", then "swapoff" and remove when done.

  6. weinzierl

    There used to be a time when not only the OS required using partitions for optimum performace (swapfiles) but also applications.

    In the late 90s databases were regularly set up in a way to store their data on raw partitions. There were other types of applications too that required partitions but for databases it was really common.

    The practice really only died with OSes allowing apps to bypass the normal filesystem cache.

    In Linux this is O_DIRECT and interestingly Linux was super late to the party because Linus hated it with a passion. Now, he was far from the only one, at least Alan Cox and Andrew Morton were skeptical, others as well. Linus was unusually extreme about it and that particular discussion is probably the single source of the majority of quotes people use against him.

  7. spijdar

    Why use swap files when we could have swap directories? ;-)

    Sprite had (IMO) a really interesting solution to swap. Each host had a directory, referenced by its host ID under the `/swap` directory, and inside that directory, individual segments of virtual memory would be saved: https://github.com/OSPreservProject/sprite/blob/master/src/k...

    Sprite overcommited memory like a modern OS, and stored segments individually so that process migration worked (if a segment was swapped-out, the path to the swap file would remain the same anywhere on the cluster, so if the process was migrated, you didn't need to swap-in the segment before migration):

    eery@cherimoya [1] > cd /swap

    eery@cherimoya [2] > ls

    1 10 11 12 13 14 15 16 17 2 3 4 5 6 7 8 9

    eery@cherimoya [3] > ls 3

    1 113 129 148 161 172 185 20 218 238 252 33 48 63 77 95

    100 114 130 15 162 173 186 203 219 24 253 34 49 64 8 96

    101 115 132 150 163 174 187 204 22 240 254 36 50 66 80 97

    102 116 133 152 164 175 188 205 221 242 255 38 51 67 81 98

    103 117 134 153 165 176 19 207 222 243 26 39 52 7 82 99

    104 12 135 154 166 177 190 209 225 244 27 4 55 70 85

    105 121 139 155 167 179 191 21 226 246 28 40 56 71 86

    106 122 14 156 168 180 193 210 227 247 29 42 57 72 87

    107 125 140 157 169 181 194 213 23 248 3 44 6 73 9

    11 126 143 158 17 182 1 […]

  8. ducktective

    Tangential, but does anyone know why in 2026 and on Debian 13, my machine still hangs when some process exhausts RAM?

    Is there really no higher-priority kernel process to prevent total freeze of the system and send a SIGKILL to the culprit process when such a scenario happens?

More from this day

2026-09-11