Stop making swap partitions—use swap files instead(gist.github.com) |
Stop making swap partitions—use swap files instead(gist.github.com) |
One nice thing about swap partitions is that they can be fixed in place even before OS installation.
(Of course, if you’re using swap enough for this to be a huge factor, you probably have bigger problems. But I haven’t done the math.)
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.
You may even have different firmware on the disks / disk controllers for database disks.
It needs an LVM partition (logical volume) because it's vertically integrated, and they are more flexible than traditional partitions.
O_DIRECT was resisted by Torvalds and others, but it's there today, and used by supposedly important platforms. Nvidia even has an API to DMA data to and from GPUs that uses O_DIRECT. There are folks working on new async WAL O_DIRECT for PostgreSQL as well.
So what can be said? mmap(2) isn't sufficient for certain cases. Torvalds has faced and successfully navigated difficult design choices in a pragmatic manner. What else?
The lesson I take is this: there are levels to implementation complexity and value. The wisdom to decide the appropriate abstraction level is crucial. You are unlikely to be equipped well enough to beneficially utilize O_DIRECT, but it's not impossible and some, in fact, are so equipped.
$ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd 3G 482.9M 86.7M 91.8M 4 [SWAP]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.
The --size and --file options are relatively new, though: they were added in util-linux v2.40, released in 2024.
I feel like if there's a malicious user (or program) on your system with the necessary access for this, you have much bigger problems.
* If you have a small root partition, the default config puts the swap file on there, wasting precious space.
* With a partition, it's easier to put swap on a separate physical device, which is good for performance.
* If you dual boot 2+ Linux distributions or installations on a single machine, as I do routinely, you can share a single swap partition between distros no problem. This means it's more space efficient and keeps down partitioning complexity.
* And of course there's hibernation, as others have mentioned.
Conclusion: no, bad advice, except for very simplistic scenarios.
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?
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] >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.
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.
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.
Debian supports swap files and has information about setting them up in the Debian wiki, so I don't know why you're implying they've taken a stand on the issue.
Better instead to make yourself informed about the tradeoffs, then make your own choice, for your setup.
See:
https://github.com/torvalds/linux/blob/827751b699b79a6e56998...
https://github.com/torvalds/linux/blob/827751b699b79a6e56998...
The thread is quoted to show that they have been functionally equivalent for several decades and yet distros continue to push outdated recommendations.
You're proudly proclaiming your lack of desire to learn or discuss on a forum meant for those things.
Go to Reddit. That's the right place for you.
Meanwhile zswap (of no relation with zfs) is free performance. Is it a rule that everything starting with a 'z' must be cool?
BTRFS in general seems more I/O constrained than ext4 or xfs so it's probably still worse to put a swapfile on a BTRFS partition, but so far my systems are doing fine.
They tend to be the last word on the subject :)
And if I have a separate otherwise unused ssd then using a swap partition simply is easier than creating a file system for it and mounting it somewhere. Block level backups also are easier.
What would be nice about swap files is if they could dynamically grow and shrink without a special setup.
Way too many variables on Linux for a one size fits all.
WHY DO I HAVE TO CONSIDER SWAP in 2026?
echo "/swapfile none swap defaults 0 0" >> /etc/fstab
Btrfs has a workaround: it can create a cow-disabled subvolume for the swapfile.
AFAIK you need a separate partition for Zfs.
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.
You do realize in the current semiconductor-short code-bloat-heavy economy we're in right now that your advocation would be prohibitively expensive for many people, yes?
At least, the gaming community would basically need to be grabbing $5K systems just because of garbage AI companies and crappy inefficient 'AI' upscaling algorithms with garbage engines that insist on doing intensive rendering optimization and upscaling on low-res models when simply rendering the regular model is faster (I'm looking square at you, UE5.) You know, that kind of thing. Plus the open world streaming, yea that's about already equal to a massive swapfile just for world data.
I think your advocation is very short on vision given current realities.
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."
Yes, but as your article notes HDDs have different performance characteristics depending on where the sectors are physically located on the platter.
If you could force the swapfile to the same location on the platter it shouldn't perform differently.
Most people are going to be using solid state where this doesn't matter.
Fortunately, the whole "load a particular firmware on the disks" wasn't new. That was something some of the HW RAID vendors recommended.
Is it possible perhaps that this advice doesn't apply equally to all situations? Is it the best for people on ZFS? Is it the best for distributions that have their own kernels builds?
I'm not saying it's a bad default, or that people should avoid it, just that it's likely not "the absolute best no questions asked" regardless of the situation, that was what I was trying to point out with my previous comment.
AFAIK, on Linux swap bypasses the filesystem. It asks the filesystem for the extents which are used by the swapfile, and does the I/O directly on the block device. This explains the many restrictions swapfiles have on btrfs (the file can't be copy-on-write, can't be mirrored, etc), but it also means the speed for a swapfile will be the same on btrfs as on ext4 or xfs (assuming a similar layout, that is, the file is not too fragmented; IIRC, the kernel prints the number of extents when you do a swapon, so you can see when it's too fragmented).
Given that every r/w filesystem you're going to use as your '/' on a Linux desktop or server supports online growing (and most support offline shrinking), it's nuts to me to hear people worrying about getting partition sizes correct. With LVM, if you get it wrong you just resize the LV and the filesystem it contains.
Hell, LVM makes swapping out disks a really easy online operation. [0] If you don't have nice hot-swap drive caddies, you might have to power off the box once to add in the new disks and again to remove the old ones, but all the data transfer can happen while the system is in use.
[0] Assuming the new and old disks have the same logical sector size, which they usually do.
https://linuxblog.io/zswap-better-than-zram/
There is a few other people documenting the same thing if you look around.
As far as Linux and swap goes, very generally speaking: if you don't have a application that specifically advises against having swap you are almost always better off with it.
If you don't end up using it then it costs you almost nothing. If you end up using it then it just makes your system more efficient because you are giving up performance for less used memory to make way for more used memory. Zswap sweetens the deal.
In the distant past having swap on a desktop was irritating because file system operations from nightly crons would end up pushing your applications into swap. Then when you go to use your desktop in the morning it will grid away at the disk until the memory was loaded back into main. This sort of behavior has been mostly solved for a couple decades now, but somehow the idea that "swap is bad and slow" still persists.
When that data doesn't compress well at all, zram is no help and traditional swap-to-storage is a better choice.
And there is a middle-ground option, zswap: swapped out pages will eventually end up on a block device, but are compressed first.
Edit: seems I got confused there, only frontswap layer was removed, and zcache
Partition resizing is not exactly difficult, and I can count the number of times I've ever actually had to resize a swap partition in the last 30 years on the fingers of one foot.
Of what distro? If you mean that the example code shows the swapfile directly under / , well of course you don't have to do it that way.
> With a partition, it's easier to put swap on a separate physical device, which is good for performance.
I think this is untrue on both counts. First, nobody is going to dedicate an entire physical device to swap, because the smallest storage devices you can get are enormous compared to the RAM they're trying to support. If the device is "separate" (from what, / ?) but still has other things on it, it's even less clear why this would matter for performance. But also it's trivial to put a swapfile on whatever device you want. It can be anywhere reasonably sane in the filesystem, you just give it a path.
> you can share a single swap partition between distros no problem
The file could go on whatever partition the distros can share. Maybe put it under /home or something. It's your system, the FHS is up to your own interpretation.
> And of course there's hibernation, as others have mentioned.
Why would that matter? You're expecting a file not to survive the low-power state?
> Of what distro?
Of any distro. I have done such configs with Ubuntu, Debian, openSUSE, SLE, Fedora, CentOS, RHEL, Alpine, Arch, you name it.
> If you mean that the example code shows the swapfile directly under / , well of course you don't have to do it that way.
Point missed. If you have a swap file created by the installer then you do not get to specify where that swapfile is, in any distro I have seen in my 30 years of working with Linux and 38 years of Unix. (Not that swap files were common on Unix in the 20th century.)
If you specify a swap partition then you choose where it is.
> I think this is untrue on both counts. First, nobody is going to dedicate an entire physical device to swap,
Incorrect assumption. You inserted "entire device" but I did not say that. A swap partition is part of a device. The clue is there in the name.
All my Thinkpads, for example, have 2 SSDs and typically I put root on the faster SSD and /home and swap on the slower SSD (or HDD). I typically configure 4-8GB of swap even if the machine has 32GB or more of RAM -- I rarely hibernate these boxes, TBH. That is plenty. If you hibernate, swap should be at least as big as RAM, or maybe 10-20% bigger in case it's already swapping when you hibernate.
> If the device is "separate" (from what, / ?)
Yes. More or less all typical Unix-like OSes read and write a lot to and from root in use, and under load, from swap. So, put them on different physical drives and spread the load.
This has been standard practice since the 1960s!
> But also it's trivial to put a swapfile on whatever device you want. It can be anywhere reasonably sane in the filesystem, you just give it a path.
It's extra manual config. A partition is one box in the installer and done. Zero manual config.
> The file could go on whatever partition the distros can share.
Again, you miss the point.
1. Distros do not by default mount one another's partitions.
> Maybe put it under /home or something.
You can but suddenly permissions and ownership become issues.
> It's your system, the FHS is up to your own interpretation.
It is preferable to do this in the installer and not worry about interpreting anything.
> Why would that matter? You're expecting a file not to survive the low-power state?
Have you read the other comments?
The smart money is on a single large partition for home and root and everything else. This way you get 100% disk availability with zero extra effort and you get maximum performance. No need to shuffle disk space around with resizing partitions or thing volumes or anything like that.
Unless you have some sort of special use case were root partition can't be shared with root then on most desktop setups having a single large partition is the most straightforward way to do things.
Hibernation isn't really something really useful anymore. If people really really want it then I don't see why they shouldn't get it... but I really don't see the point.
systemd-oomd should be integrated in systemd, you can configure it to your liking and see if it improves your problem.
Chris Siebenmann discusses when the OOM killer triggers: https://utcc.utoronto.ca/~cks/space/blog/linux/OOMKillerWhen
Chris disables systemd-oomd after it obliterates his X session with no explanation: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdOomdNo...
Made it far easier to target any containers that got too hot rather than ever risk anything higher priority.
User-space OOM killers never really worked for me and imo are not a proper solution anyway. This option instead lets you make the kernel OOM killer actually work for desktop use.
Currently have it set to `1000` and it works very well for me (don't remember the last time I had a full system freeze due to OOM).
It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind, so your experience might not be as good as you were hoping for.
Making a massive swap space helps a little bit. It's better to just never let your actual memory usage go above 85% to 90%. It's fine to go above if you're trying to optimize a server with a specific set of processes to wring every last bit of efficiency out of it, but not for general desktop computing.
If it really bothers you OpenBSD (edit: thanks for the reminder TimTheTinker) and Illumos don't allow overcommit at all and Windows handles this situation much more gracefully, so WSL is an option too. If you don't mind Oracle (i do), solaris also doesn't allow overcommit.
…by default. It can be disabled via a sysctl:
* https://www.kernel.org/doc/Documentation/vm/overcommit-accou...
In a nutshell, overcommit. It's more or less broken by design but it's also incredibly practical so pretty much everyone does it.
Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?
In all cases, yes, in some cases no, you can make some heuristics for common use cases
For example, if I have 3 process hogs, on desktop I'd rather have my dev containers be killed, than anything I'm using.
Or on server, I'd rather have anything else but SSH/VPN software killed, because that's needed to debug the problem.
I recommend using the earlyoom if you want more aggresive oom kill:
https://github.com/rfjakob/earlyoom
The README contains a lot of interesting information.
It took a long evening to figure out that it gets earlyoom'd immediately because it tries to allocate too much. Previously the very familiar hitching and freezing was a very easy sign of what kind of issue I was dealing with
If you know ahead of time which programs / processes are at risk of unacceptably high memory usage, check out "ulimit".
If you are you using disk swap - not sure why would if you have a SSD, but I once heard some justification for doing that - then install early OOM.
Or zswap instead of zram.
https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-...
And since that happened on all nodes around the same time, it took out the entire cluster. If you are not familiar, random, uncontrolled node restarts in any kind of multi node database or search product are a great way to trigger outages. So, not great.
I've had quite a few encounters with the oomkiller killing processes that were important and didn't need killing. Or as I like to phrase it "killing the one reason this server exists".
These days the way to size a server is "have enough memory to run whatever you need running + at least half a GB for whatever apt might randomly demand at any point". And guess what, memory tends to be expensive in cloud environments so people tend to get vms with as little as half a GB of ram.
The culprit turned out to be the kernel itself, and rolling back to a 6.1 series kernel made the problem go away. I see that Linus's love for vibe-coding is already paying dividends.
I ran a small Mosix cluster a couple times just for funsies. I had forgotten about Sprite as the other SSI cluster operating system. It is really too bad that this line of research trailed off.
The Sprite kernel released by UCB doesn't run on any qemu target, but I've made ports to the PC and to sun4m, which qemu can run. I've gotten the sun3 (m68k) and sun4 (sparc) ports to run in phabric's fork/continuation of TME, NME [0], but the Lance emulation has a bug that'll cause some longer Ethernet frames to have a few bytes lopped off the end (kernel panics on RPC calls!) and the m68k MMU is missing an edge case that makes init segfault right after exec(). Need to upstream those sometime...
I've been running my cluster mostly off a mini PC with an N95 Atom CPU (root server + couple hosts to login to, Sprite's local filesystem path is buggy and shouldn't be trusted), with virtio network and storage drivers ported to Sprite. Sips electricity, and plenty fast storage for everything else. Migration works great between a real 486 PC compatible and my Zen5 desktop, along with some real SPARCstations mixed in there, and a SPARC laptop for fun.
I wanna release it some day, it'd be super easy to deploy new clusters with a single qcow2 and maybe a libvirt XML domain, but the code is currently a mess and still missing stuff, like a working `addhost` command (the provided one is just a csh script which checked files in/out of an RCS repo in /etc, with hardcoded paths to host mounts at Berkeley...)
But I've found that even with no/little swap, the system can get into high memory pressure situations (even easier because it can't swap out unused pages of libraries and the like), and still go into a sort of thrashing state even though it isn't swapping.
My main workstation is a Dell XPS15 with 32GB of RAM and I had 8GB of swap on it. About every month the system load would skyrocket even though it had plenty of mem+cache+swap available. If I killed off my browser and slack, load would return to normal, and I could use the system for a few more days or a week before it happened again.
I struggled with this for a year or more, before (for reason's I don't remember), I added another 8GB of swap. Within the next day 80% of the extra swap was used right up. I decided to swapoff that new file and create a 64GB swapfile and just see what happened. It got to around 20-30GB IIRC before it leveled off. And, more importantly, over the next 100+ days I never had that thrashing happen again.
That was with Ubuntu 22.04. I just recently (May-ish) switched over to a NixOS setup with 64GB of swapfile, and it's been very stable.
(They obviously don’t page out, they are just discarded and read again when needed)
Not as big of a problem as it used to be. Both because OOM killer has gotten better and also web servers are such a commodity that remotely cycling them isn't going to cause a outage and is the quickest and cleanest way to get them back into production.
That's probably not right with today's RAM sizes but I'm not sure what the current rule is. I just go with the Ubuntu installer default but I don't know if that's just a fixed number or computed in some way from amount of RAM available.
Note that RAM is much, much more expensive than disk space. If I can sacrifice some of the latter to potentially get some of the former, it's usually a nice trade for me.
Even if you have plenty of ram, having swap can help with performance.
Why? Because the OS can page rarely used or seemingly downright unused dirty pages to swap, freeing up precious RAM for caches.
I'd hazard a guess that especially if you run a ton of containers this can help, as there's probably a lot of memory getting dirtied on initialization of containers and their processes, which ends up never read afterwards.
I always set up swap, because sacrificing some disk space in potential exchange of free RAM, which is orders of magnitudes more expensive, is a nice prospect.
Not a big deal. Being efficient isn't really all it is cracked up to be. Sometimes having a big server that sits mostly idle is a good trade off for what you want to accomplish.
In consequence, I always give swap. Even on the off-chance it ends up unused, disk space is orders of magnitude cheaper than RAM, so I don't mind sacrificing it for potential gains.
Also generally swap is recommended on all systems. During normal use it should rarely be needed but if it's needed it prevents spurious crashes. E.g. make -j16 shouldn't result in a hard to comprehend crash because I miss 1 GB of RAM.
That maybe reasonable advice if you never intend to hibernate your desktop. I like to shut my desktop down when I'm not using it, and it's nice to be able to quickly boot it back to the same state it was in when I went to bed.
Why I'm not sure this is a bad idea: a pathological process that quickly captures the entire allocated disk space will be contained by this layout and will likely not affect the system as a whole. Consider, for example, a process that excessively logs into /var/log: once the filesystem mounted at /var fills up, it might fail / hang, but you will still be able to use stuff from /bin or /sbin. But, if your entire root filesystem fills up, you probably won't be able to run any applications at all.
Hibernation?
(ZFS might be described as the love child of lvm and btrfs, 'cept ZFS got there first)
( Very briefly: you hand ZFS a stack of disks (in mirrors or raidz groups, for redundancy) and it makes a zpool. Then you carve the pool into datasets as needed. Each dataset looks like an ordinary directory and takes only the space its files actually use, so you never guess partition sizes again. And each one can have its own compression, snapshot schedule, quota, encryption, and send/receive backups, etc etc etc. )
Performance of zvol is worse than for LVM logical volumes. Last I've looked, zvol for swap is just asking for trouble, up to and including deadlocks. ZFS filesystems do have weird edge cases and incompatibilities, e.g. around free space reporting, quota and the like. And support with software vendors e.g. for enterprise distributions or backup software is spotty at best.
But even for the "frequently reinstalled cattle"-usecase, LVM has benefits, e.g. snapshots for backups, debugging and forensics.
I use LVM on all my non-appliance Linux systems, [0] both servers and desktops. Given that few (no?) filesystems support online shrinking but every one that you'd use as '/' supports online growing, my strategy is to take a fairly conservative guess at how big my various subdirectories need to be and leave most of my available space unallocated. Later on, if I -say- find that I need more space in '/' or '/home', or prevent a blowup in '/var/log' from eating up all the space in '/' by putting that on a separate LV, etc, etc, it's just a few commands [1] and the job's done.
[0] ...someone else has configured the storage scheme for the appliances, and I'm not going to override their choices...
[1] ...and some data copying in the case of backing a subdirectory with a new volume...
Swap on primary partitions also complicates dump and restore, although hardly anyone seems to know what backups are now.
https://utcc.utoronto.ca/~cks/space/blog/linux/HowSwapFindsB...
And there are many things that complicate dump and restore. Dump and restore often need to account for what partitions were created, anyway, so don't swap partitions also complicate it?
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SwapfileAn...
Linux can work with TPM but it's never as smooth. (Unless I guess you make it custom for your specific setup.)
You'd need to keep secure boot on, preferably with your own keys loaded, to get all of the benefits, and that's a bit harder to automate.
Windows does all of this and more. It's harder on Linux because of a lack of tooling/interest/business incentives, and because on average Linux users want more control over their hardware than Windows users.
Windows and Linux run on the exact same hardware. Windows hibernation doesn't rely on secret bios features.
Unreliable hibernation is 100% and undeniably a Linux problem, there is no secret advantage or conspiracy to keep it down. It's just that nobody cares enough to make Linux not suck.
Why should we care about what the installer does when it's trivial to change later? You said this is "bad advice, except for very simplistic scenarios" but people not in "very simplistic scenarios" are perfectly capable of running a few shell commands.
Aside from which, typical home users are in very simplistic scenarios. The Mint installer defaults to a single partition aside from what's required for booting, and a swapfile at /swapfile. And tons of Mint users are doing just fine with that. They are not realistically going to distro-hop because it won't realistically solve any problems for them.
Your overall argument seems to depend on accommodating some hypothetical power users who nevertheless want the installer to get it right for them. But in this case, why not petition the distro to improve the installer instead?
> This has been standard practice since the 1960s!
And? the point here is to identify a benefit of putting swap on a carefully chosen partition that cannot be realized by putting swap on a file at a carefully chosen path (since that choice also implicitly puts it on a specific partition).
> You can but suddenly permissions and ownership become issues.
I can't fathom why. I said /home, not ~.
> Point missed. ... Incorrect assumption. ... Have you read the other comments?
I consider this sort of commentary incivil (and the commenting guidelines support me in this).
I also did not make an assumption at all; I considered one of two alternative meanings without introducing it with the word "if". That's why the second possibility does start with "if". This is just a rhetorical technique, dismissing the most absurd interpretations first exactly because they are easier to dismiss.
And you find my response "uncivil" but I find yours very much so as well. You won't even entertain my use cases, and my own direct personal experience, but your bad advice that would have repeatedly lost me all the data in my home directory on my work PC if I used your methods, for you trumps my 38 years of Unix experience.
No. You are being dogmatic, inconsiderate, not listening, responding with ridiculous strawman arguments ("keep swap in your home directory" as a response to "duplicate swap files waste space" -- that is ridiculous) and mockery.
You are rude, and you are arrogant, and you are wrong.
I am not being any more dogmatic or inconsiderate than you. I have listened to you quite carefully, and explained in good faith why I think you are wrong based on my best effort to understand you. But you have still not, as far as I can understand, identified a benefit of putting swap on a carefully chosen partition that cannot be realized by putting swap on a file at a carefully chosen path (since that choice also implicitly puts it on a specific partition).
In particular, you are the one who proposed that using swap files would require duplication, and I explained why I disagree. You claimed vaguely that there would be permission issues; when I expressed confusion, you did not elaborate. You have yet to give any concrete reason why there would be duplicate swap files, therefore the fact that duplication wastes space is moot.
My assumption was that you would be sharing /home between the two installations, because there is really nothing preventing you from doing that, and because making two separate /home partitions wastes much more space (because you don't know ahead of time how much space you'll use with each). Unless perhaps you do some bind-mounting trick that I would consider much trickier than setting up a swapfile at a custom path. (/home is owned by root, so there should not be any permission issue with a swapfile at /home/swapfile . If you disagree then you should explain why instead of being vague and dismissive.)
Nothing I said could reasonably be considered "mockery" in any way, shape or form. You are the one engaging in "mockery", by describing my proposal as "ridiculous" in italics without giving any reason as to why it wouldn't work.
Just found this comment:
> > [...] If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it. [...]
> By having the user@.service template be enrolled in systemd-oomd, Fedora made the cgroup that systemd-oomd would select to be killed be all of your processes (across all of your sessions, if you have more than one). ...
Maybe *Fedora* has fixed or improved in the last 4 years. Or maybe they don't run Fedora.
In my experience it works really well. I wonder why my computer is a bit sluggish, and find out I have several gigs in zram.
If that was in swap on a disk, it would be really painful.
The problem with turning it off is that the system and applications have been architected assuming that it will be on, so things like fork/execing a memory heavy processes or allocating memory inside a cgroup (which still pretends overcommit is enabled and there's still no way to disable that assumption) that used to work fine might break with no good way to get them to work again. This comment (and siblings) have more specifics: https://news.ycombinator.com/item?id=27794237#27795199
The OOM killer looking at processes and seeing a giant one, using 90% of the physical memory and growing fast and deciding "Oh, that's ok because it is working hard, I'm going to go kill this little tiny thing that hasn't been used recently called sshd". Inoculating sshd against the oom killer is SOP now.
But while I don't have any hard data, I imagine that depending on the workload, there can be a punch of pages that are read during initialization, or a one-off workload, and never being read or freed up afterwards.
Just try activating a swap file, and see if it gets any usage, despite memory pressure being low.
Which was always a dumbass rule that made no logical sense.
Like, I remember a time when I had 4 GB of RAM and had my swap set to 8 GB. Then I upgraded to 16 GB of RAM. Theoretically, I shouldn't even need a swap file anymore, since my old setup would max at 12 GB and yet I never had OOM problems, but that "rule of thumb" would dictate that I should increase my swap to 32 GB.
I remember when I first came across this rule when getting into Linux for the first time. If memory serves, I had 256MB of RAM, so I set swap for 512MB, which seems perfectly cromulent.
The other part was that it kinda matched the money you were spending on the machine.
The guy with 128MB of ram could likely afford to spend the extra disk space on a swap partition then the guy stuck with just 32MB.
If it's killing your email editor then your email editor is bloated or you just need more RAM - or swap.
Page cache duplication has been greatly lowered in last decade
It seems to work well in a variety of situations: 4GB/single-slow-SSD ancient systems work just as well as spinning rust bulk storage pools with NVME ARC/ZIL caches for my gaming/server/database datasets, and all-SATA-SSD pools can get to near-NVME performance with bonus redundancy for boot volumes and latency-critical stuff. For personal desktop use, I haven't found dedup worth the squeeze in RAM costs and tuning (it works, but it's generally easier to solve most dedup-compatible problems at a layer closer to the cause).
ZFSBootMenu and the ability to roll back to snapshots and restore/maintenance disks from outside of the primary operating system, without having to think about fallback boot drives or physical backup volumes, is a godsend in the "try random sketchy commands that might trash my installation in order to get a low-level driver problem resolved" and "I could take the time to understand what this curl | bash invocation does, but I have better things to do; I want to be able to reverse it if it breaks stuff" departments.
In general, I strongly recommend ZFS for daily-driver use. Its core primitives are quite flexible, it makes redundancy/backups/drive addition/replacement easy, and it works fine on old and under-resourced systems; the mythos of "it requires ECC and enterprise-grade hardware and tons of RAM/CPU to work at all" was always bunk. The enterprise/SAN features are there if you want them, but are off by default, and the core FS capabilities are widely useful. Even casual desktop Linux users would do well to set it up, since there are a lot of rare-but-real ordinary user needs that, if they come up and you're not running something like ZFS, can't be done at all unless you connect purpose-specific hard drives or reinstall your OS.
Especially now that NVMEs are so expensive, ZFS should be considered for its ability to make RAIDing up a set of slower drives (or mostly slow drives with an NVME cache) very easy. That way, you can make your existing disks into something that performs well enough that you don't need to spend money on new hardware.
Just don't install it via DKMS; get a distro that ships it compiled into the kernel or as an installable kernel-paired module. Many such distros exist. The DKMS edition won't eat your data, but you'll get real tired of failed system updates because the kernel changed some source and the compile failed. That happens often; turns out that the volume of the kernel API surface used by something as massive as the ZFS codebase is quite large.
Edit: upon reading back through this, I'm a bit sheepish that I sound like such a breathless shill. I promise I'm not in the ~pocket~ zpool of big filesystem. I just like it.
Not true at all.. but most large object storage redundancy has moved to the application layer. There are still workloads that are a great fit but I agree OpenZFS is currently not well suited as a general purpose FS.
As someone who originally ran it on Solaris when it came out ~20 years ago, and have continued to run it on FreeBSD and Linux, I would disagree.
https://lkml.iu.edu/hypermail/linux/kernel/2103.0/06524.html
The bug is in here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
This was 2021, and while this bug is fixed, maybe take Linus's advice. Rely on a partition for primary swap, and only add files if you need to. Don't put them on the root partition, preferably a second disk.
I can't resolve your links but this is a good reference: https://kernel-internals.org/mm/swapping/
Normally dump skips swap partitions entirely, and doesn't know anything about partitioning. Swap will refuse to activate on a non-mkswap partition so there is reasonable protection when you're migrating.
https://github.com/SymbioticLab/Infiniswap
Great hack for when you have a massive working set but don't want to rewrite the code to be distributed/parallel.
Here's a good summary of what it actually does. https://chrisdown.name/2018/01/02/in-defence-of-swap.html
TL;DR that swap shouldn't be seen as "spare RAM", but a mechanism for paging out anonymous pages, which is desirable in many circumstances in avoiding OOM situations and making memory management work better. It paradoxically typically reduces I/O thrashing.
But why reject taking apparently-free steps to soften the blow?
Is there some advantage in making sure that when the wall is hit, it is hit as hard as it possibly can be?
You should have a much better “plan A” to avoid this situation.
this guide should help make it less likely for sshd or your login shell to get killed: https://ianlpaterson.com/blog/oom-lockout-ssh-survival-harde...
But where linux would automagically back those pages once you use them, Windows requires you to actually ask for those pages to be backed by something (physical memory or page file) by calling VirtualAlloc with MEM_COMMIT on the range you actually want to use
If that's the only issue, it's avoidable for most use cases. Lots of processes that fork are doing fork/exec to run a helper program. If they know they will do that and that they will be a large process, it's often useful to setup a fork/exec helper in early application startup.
However, there are some applications that use CoW more intentionally. Lock -> fork -> (unlock in parent / persist coherent snapshot in child) is a common pattern; I believe redis uses thst pattern and I've seen it mentioned in discussions about MMO servers. I believe postgres uses fork and CoW for transaction isolation ... but postgres also runs on Windows so there must be another way or I don't understand.
For the persist case, you could imagine some sort of flag to fork to allow overcommit and maybe even to let CoW requests stall in the parent rather than fail... the child is expected to do its work and exit in a limited time.
I'm sure there are many reasons why Linux can't do that by default, but it's a real shame.
Given that one can have swap files, and can also use LVM LVs for swap, and given that userspace OOM killers that work way better than the built in one -for some workloads- exist, I see no reason why you couldn't have this on Linux. This comment [0] mentions a project that claims to do just that -and seems to use swapfiles to do it-, but I don't have any experience with it.
FWIW, I did find the README by the original author [1] far more informative than the one written by the new maintainer.
I get the hibernation argument, but not the arguments implying swap is always better.
Actively using 60GB RAM and moving 4GB of unused pages to swap (60+4), is somehow faster than actively using 60GB RAM and keeping unused pages in the remaining 4GB RAM (64+0)?
EDIT: If you prefer more round numbers, feel free to replace them with "32GB RAM + 32GB swap" and "64GB RAM + no swap" respectively.
What does the OS do differently with swap vs RAM? What can I do with swap that I cannot do with RAM? Things like that.
Say you have 64GB of RAM, of which 4GB are dirty pages that are never, or at least very rarely, accessed. With 64GB RAM + 4GB swap, you filled up your swap with them and have 64GB RAM left to use actively. With 64GB RAM + 0GB swap, you only have 60GB RAM left to use actively.
Use the 32+32 numbers if you're more comfortable with those round numbers.
If I have a system running comfortably with 32GB RAM + 32GB swap (no OOM, no swap thrashing), and I upgrade to 64GB RAM + 0 swap, what actual negative effects would I be getting for the lack of swap?
That's my question, to know if swap has any benefits other than being additional slow RAM.
We use swap because we have plenty of disk space, but (comparably) very little DRAM.
The same goes for another level on the hierarchy: If you could choose between 1GB of DRAM vs. 1GB of SRAM (which your CPU cache is), you’d definitely choose the SRAM. But you’d be paying out of your nose both with money and area, it’s not economical at all. My CPU has 96MB of cache, and that’s considered massive.
So, the typical saving is tiny, and the cost in unpredictable performance is quite bad.
If you really do have an issue with “lost” dirty memory, your time is best spent addressing that directly.