alt Hacker NewsStop making swap partitions—use swap files instead
Comments
> 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.
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]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.
[delayed]
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.
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 197 214 230 249 30 45 60 74 90
111 127 145 159 170 183 198 215 233 25 31 46 61 75 91
112 128 146 16 171 184 199 216 237 250 32 47 62 76 92
eery@cherimoya [4] > ls 5
82 83
eery@cherimoya [5] > ls 15
111 126 14 155 17 181 217 253 4 57 72 86 98
116 131 141 160 170 19 24 29 47 62 77 9
121 136 150 165 177 210 25 34 52 67 8 95
eery@cherimoya [6] > grep cherimoya /etc/spritehosts
12 pc386 cherimoya.shockfox.net cherimoya
eery@cherimoya [7] > ls 12
eery@cherimoya [8] >Remember when distros used complicated partition setups, one for /root, one for /var one for /home, a swap partition etc. Was always a bad choice because one of them would be at 99% while others would linger below 10%
For swap, the best advice is to disable swap on your desktop, unless <8GB RAM. Really, I've never needed it and you probably won't either.
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?
Typically I see admins create partitions as basically failure domains - if one fills up it doesn't explode things relying on the others. Wouldn't this be worse in that regard? If you end up accidentally filling up your entire disk, you can no longer swap. Vice versa, if you swap aggressively you could end up filling the disk and then break a running process.
The exception is if you use CoW filesystems.
Btrfs has a workaround: it can create a cow-disabled subvolume for the swapfile.
AFAIK you need a separate partition for Zfs.
Most file systems get cached in ram, which is unlikely to have happy consequences when scarce ram triggers use of the filesystem swap.
swap files make setting up hibernation a bit more complicated - in most cases the file has to be contiguous, e.g. you have to defragment it once after allocating. Then, you need to tell the bootloader the byte offset of the file on the partition.
Every rule has an exception. Beware of this advice on zfs, for instance.
Meanwhile zswap (of no relation with zfs) is free performance. Is it a rule that everything starting with a 'z' must be cool?
> Swap files have had the same performance characteristics as swap partitions for more than 20 years
I thought so too, then I benchmarked it on a (spinning rust) HDD and found it was significantly slower:
https://www.vidarholen.net/contents/blog/?p=1110
tl;dr: "In this test, using a swap file was surprisingly 50%+ slower than simply allocating a swap partition at the start of the drive, in spite of the low fragmentation and Linux’s bypass of the FS layer."
Swap files are also much easier to set up than partitions if you're using full disk encryption.
systemd-oomd killing your whole session because Fedora enrolled [email protected] is nasty. A swap file won't save you from the OOM killer, just delays it.
Interestingly I always use swapfiles and this page made me realise there can be a performance impact if the filesystem is old - the lkml link says as long as the swap file isn't fragmented there's no impact
Or be a proper computer user and have a full drive on its own dedicated bus for swap. There is literally no point in time where a full swap drive is less performant or useful than swap directories or swap files (and swap files are a relic of the 90s when a single application would need gobs of virtual memory.)
Funny watching someone advocate going back to something that sucked when we have far more performant hardware today which makes most of the other stuff wholly irrelevant.
It would be nice if the VFS had a hook for providing swap pages, making this manual futzing less necessary.
Yeah, no. I don't care if I have 128gb or 2tb of ram, or what I'm doing with it (but especially in live/realtime scenarios), I'm always going to have at least one nvme dedicated entirely to swap.
i cannot hibernate in a swapfile in zfs
Linux distros that do use swap files do so statically. It doesn't handle dynamically growing and shrinking it like other operating systems.
Oh, the irony of:
echo "/swapfile none swap defaults 0 0" >> /etc/fstab
No.
It's a terrible idea to delegate swap, a capability that is expected to operate under severe memory pressure, to a subsystem that fails under such conditions.
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.)