Stop making swap partitions—use swap files instead

Posted by jenders 3 days ago

Comments

Comment by weinzierl 1 day ago

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.

Comment by mitxela 12 hours ago

Ceph still does this. In fact it migrated the other way - it used to use a file, and now wants a partition.

It needs an LVM partition (logical volume) because it's vertically integrated, and they are more flexible than traditional partitions.

Comment by kjs3 20 hours ago

If I recall correctly, Oracle best practices back in the day (waaaay back) was always put the DB on raw partitions, which caused us some issues with existing tooling. I've been fortunate enough to not have to pay attention to Oracle best practices in quite a while.

Comment by angry_octet 14 hours ago

High performance databases still use raw I/O. You get much better control of data placement and write ordering, without filesystem confounders. With traditional spinning rust being replaced with SSDs and SMR it can be even more important.

You may even have different firmware on the disks / disk controllers for database disks.

Comment by RiverCrochet 1 day ago

was this before mmap(2)?

Comment by topspin 1 day ago

mmap(2) in Unix predates Linux itself by several years (1988 Sun, 1990 BSD). mmap(2) was present in Linux well before any of the high performance databases, file systems and other applications that use(d) O_DIRECT appeared on Linux.

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.

Comment by klodolph 1 day ago

Well-put

Comment by mitxela 12 hours ago

mmap makes database performance worse, not better, because it makes all I/O blocking.

Comment by rini17 1 day ago

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]

Comment by kees99 1 day ago

zram is a good choice when data in RAM is very repetetive/compressible. Web browsers is one such load. Android apps is another good one.

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.

Comment by fpoling 1 day ago

Zram also supports a block device for pages that do not compress. So the primary advantage of zswap is that one can use its swap for hibernation while it does not work with zram.

Comment by MrDrMcCoy 22 hours ago

Zram support for a block device is quite misleading, since there are no automatic mechanisms for enabling this. You have to build your own daemon to scan pages and take action on them. Zswap doesn't have that problem.

Comment by tmtvl 4 hours ago

Nah, zswap is way better than zram: <https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-...>.

Comment by rini17 2 hours ago

zswap is back in kernel?

Edit: seems I got confused there, only frontswap layer was removed, and zcache

Comment by fpoling 1 day ago

On x64 CPU for laptops the memory bandwidth is rather limited and a fast compressor like lz4 can saturate it. As the result latest SSD are faster then z-ram when using hardware encryption on SSD.

Comment by Rohansi 23 hours ago

If you care about performance you shouldn't be running from swap period. Swap is just a safety net.

Comment by ssl-3 23 hours ago

It's OK to care about the performance of the safety net, too.

Comment by MrDrMcCoy 22 hours ago

Swap is so much more than a safety net and can increase performance if used correctly. See Chris Down's "In defense of swap" and follow-up that breaks down zram vs zswap.

Comment by fpoling 23 hours ago

Swap is required for hibernation. And with fast ssd or properly tuned zram/zswap one can run task that use 10%-20% more memory than installed RAM. Surely there is a slowdown, but it is not that big especially when SSD can read write more than 5GB/s.

Comment by marginalia_nu 21 hours ago

Swap actually helps with performance for the most part.

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.

Comment by Rohansi 17 hours ago

It helps with performance by allowing your system to have more free physical RAM. And by free I mean for caches. It does this by moving data from inactive pages out of physical RAM. You shouldn't care about the peak bandwidth of zram vs. ordinary swap because latency matters more.

Comment by CJefferson 20 hours ago

I mean, are you saying ‘but more RAM?’ because obviously yes that’s true but not a solution if you already own a laptop, and have you seen ram prices? Also swapping to a fast SSD isn’t like it used to be on spinning discs. I’ve been amazed how responsive Mac neo laptops are and they are swapping all the time.

Comment by Rohansi 16 hours ago

I'm not saying to avoid swap. It is great at what it was designed to do. I only take issue with optimizing swap for bandwidth when it will never be able to keep up with RAM bandwidth. The MacBook Neo for example has 60 GB/s of RAM bandwidth but only 1.5 GB/s SSD bandwidth.

Comment by ssl-3 14 hours ago

Obviously, running out of memory and resorting to swap (or other safety nets) is less than ideal.

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?

Comment by Rohansi 10 hours ago

Because it wouldn't soften the blow. Swap benefits the most from improved latency not bandwidth. Data is moved from swap back to physical RAM when swapped out pages are accessed by software (which stalls the thread). The kernel has less insight into the memory access pattern to prefetch the next page so the stalls likely continue for each page it needs to restore. The latency of zram (compressed in memory) is still lower than the fastest SSDs which reduces those stalls.

Comment by MrDrMcCoy 22 hours ago

Zswap is even better than that. Give it a try sometime.

Comment by LelouBil 12 hours ago

On Bazzite I had to use a swapfile and disable zram to have hibernation working

Comment by lotharcable 14 hours ago

Zswap has improved to the point where it is now preferable over Zram.

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.

Comment by cesarb 1 day ago

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

Comment by jwilk 1 day ago

Also, fallocate+chmod is racy: between the two calls, an attacker could open the file, and then keep it open until next reboot. OTOH, mkswap creates the swap file with the correct permissions straight away.

The --size and --file options are relatively new, though: they were added in util-linux v2.40, released in 2024.

Comment by zahlman 21 hours ago

> between the two calls, an attacker could open the file, and then keep it open until next reboot.

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.

Comment by jenders 21 hours ago

Looks like this was added in util-linux 2.40. Works with btrfs correctly too! Added.

Comment by jenders 23 hours ago

I wrote this years ago before LLMs made it easy to validate guesswork. I’ll update! Good call

Comment by bigstrat2003 17 hours ago

LLMs are guesswork. You have to validate them, not the other way around.

Comment by lproven 22 hours ago

Couple of things this didn't consider.

* 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.

Comment by zahlman 21 hours ago

> If you have a small root partition, the default config

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?

Comment by dwattttt 20 hours ago

GP is not presenting these as evidence for an approach, just notable facts that weren't initially obvious.

Comment by zahlman 46 minutes ago

The comment concludes with "Conclusion: no, bad advice, except for very simplistic scenarios.", so I don't think I can agree with you on this. My point was that these facts don't (in my analysis) support the conclusion, and suggest a contradictory stance (in particular: planning in advance to dual-boot multiple separate distros, but not being willing to adjust the configuration after installation).

Comment by lproven 11 hours ago

I think you're wrong on every single point you make.

> 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?

Comment by zahlman 49 minutes ago

> If you have a swap file created by the installer then you do not get to specify

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.

Comment by efaref 9 hours ago

It also clouds disk usage stats, as a big chunk of your root device is taken up by the swap file. I'd rather look at `df /` and see the size of my OS installation without anything else.

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.

Comment by lotharcable 14 hours ago

There are lots of very good reasons why running small root partitions on Linux desktops is a very bad idea.

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.

Comment by lproven 11 hours ago

I disagree on every single point.

> There are lots of very good reasons why running small root partitions on Linux desktops is a very bad idea.

Go on then: name them.

I give root about 2x the space I expect it to take when fully populated. 4x if it's a very big disk. The rest is for me, not the OS.

> The smart money is on a single large partition for home and root and everything else.

With all due respect and deference:

Drivel. Absolute piffle. This is in fact the reverse of the truth.

Maybe you are young and inexperienced but I have bad news for you: OSes crash sometimes.

When (not if) they crash, volumes that they they have open files on tend to get corrupted. This is an especially key problem with some filesystems such as Btrfs that do not have working repair tools.

You should always keep your own data on a separate partition at least, and ideally, a separate physical drive. It will have less wear and that makes SSDs last longer.

In the last decade, keeping my OS on a different volume from my data in `/home` has saved my work at least 5-10 times. I work in the Linux industry. I work with testing OSes. But even on stable OSes, I've seen them crash far more than I'd like. Sadly, in my extensive personal experience, Btrfs is notably unstable and unreliable, and it fails frequently in normal routine operation, especially on snapshotting OSes such as openSUSE.

Always keep `/home` somewhere else, on a different disk format, for safety. XFS is good, but difficult to resize or repair. Plain old ext4 is very good in terms of repair tools.

> This way you get 100% disk availability

Until it fails

> with zero extra effort

Extra effort in setup is FAR preferable to extra effort in data recovery later.

> and you get maximum performance.

The opposite of the truth.

Swap on a different physical drive is faster.

Spread the load across multiple media for performance. That is how server OSes do it, because it is faster.

Any decent NAS OS will compel you to install the OS on different physical media from the data volumes for this specific reason.

You literally could not be more wrong.

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

Easiest does not mean best. Best is usually not simplest or easiest.

Wrong again.

> Hibernation isn't really something really useful anymore.

Absolute nonsense. Your own experience does not mean universal experience.

Comment by akerl_ 8 hours ago

You’ve tainted your otherwise interesting comment pretty intensely by mixing in this level of condescension and hostility.

Comment by NBJack 6 hours ago

I, uh, would be more careful of making that statement given our public comment history. I know I can't cast any stones here.

More than interesting though, I will vouch for many of the points they presented in practice. Spreading partitions and taking advantage of the flexibility of Linux with how and where they are mounted has been a part of best practices for decades now. Many cloud-based solutions for Linux workstations I've used take full advantage of this for easier management of space (i.e. volume expansion) as well as security considerations, to say nothing of keeping your /var/log separate to avoid running out of space because you turned on verbose mode for something.

Comment by akerl_ 5 hours ago

I’m not sure what you’re trying to say.

I deserve to be called out just the same if I’m wrapping good points with “Drivel. Absolute piffle.” and “Maybe you are young and inexperienced”.

Comment by Delk 3 hours ago

> In the last decade, keeping my OS on a different volume from my data in `/home` has saved my work at least 5-10 times.

Mine is of course just another anecdote, but despite seeing some crashes or hangs over the years, I can't remember the last time I've even had to manually fsck my ext4 filesystems, and I'm honestly not sure I've ever seen any unrecoverable corruption on ext4 or ext3. (I'm not saying it doesn't happen, as it certainly can, but I wouldn't think it's that common unless you're operating on a fairly large scale. And before journaling filesystems, crashes were of course a whole different deal.)

I used to keep /home separate on my personal devices (and maybe some other partitions as well because it was "a good practice"), but for more than a decade now my personal devices have had everything on a single large root fs, save for /boot and swap.

I've stuck with rather conservative fs choices and haven't used btrfs much, so I don't know if the story is different there.

What you gain with a single large root partition is of course that you don't need to know in advance how much software you'll want to install under /usr or how much space you'll need for /home or /var.

Multiple partitions can certainly be a good idea from a system management point of view, for cases where people either want to actively manage the system, or when their needs are demanding enough that it's warranted. If I were deploying a server for any kind of real use, yeah, the database or the server logs would certainly not be on the root volume.

But in case of desktops or laptops, most people, even engineers, don't really want to be meticulously managing their personal computers. Nor are most people's personal computing needs that demanding. The convenience of not running out of space on a single partition because you guessed the your future needs wrong wins over.

> Swap on a different physical drive is faster.

> Spread the load across multiple media for performance. That is how server OSes do it, because it is faster.

Of course it is, but in contrast, laptops don't really tend to have separate physical drives on which to put swap. I doubt most people would care enough about swap performance to install a separate high-performance drive for it even in desktops.

With that said, I also do keep a swap partition even on personal computers, and hibernation can be useful. (I think there are some issues with hibernation and encrypted swap in Linux, though, so I haven't bothered with it in a while).

Comment by ghostly_s 1 day ago

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.)

Comment by vor_ 15 hours ago

Respectfully, what a stubborn position to take. You don't want to listen to anyone else, and you don't want to be taught any new information about it that might change your mind.

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.

Comment by embedding-shape 23 hours ago

Also, this seems to be based on a email from 2005, about kernel version 2.4 and 2.6, and their differences. Things might have changed since then, and also depends on a lot of factors, not the least what filesystem you use. I'm not sure people should seriously follow advice that basically boils down to "do this always it's best".

Better instead to make yourself informed about the tradeoffs, then make your own choice, for your setup.

Comment by jenders 21 hours ago

This recommendation is based off the current implementation.

See:

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.

Comment by embedding-shape 9 hours ago

> yet distros continue to push outdated recommendations

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.

Comment by rddbs 21 hours ago

Just because there might exist tradeoffs doesn’t make them matter to someone. If you’re using a Linux distro then you’re already living off thousands of decisions made with tradeoffs and it’s hardly feasible to be informed or care about all of them.

Comment by throw10920 15 hours ago

This is one of the most anti-intellectual and unsuitable for HN comments I've ever seen.

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.

Comment by angry_octet 14 hours ago

It's actually incredibly sensible not to just make changes to core OS settings unless you know what you're doing. There are good reasons not to use swap files, which become evident in OOM situations.

Comment by LtWorf 13 hours ago

How does a swap file vs swap partition change things in OOM situations?

Comment by angry_octet 8 hours ago

As @mitxela says, if you need to fault in a page which is needed for some critical OS function, which requires going through the VFS layer, and that requires paging in another page, which has been swapped out due to memory pressure ... There are many edge cases.

Swap on primary partitions also complicates dump and restore, although hardly anyone seems to know what backups are now.

Comment by ButlerianJihad 8 hours ago

See, the thing is that swapping or paging to a file does not use the VFS layer, except when activating or deactivating it. So swapfiles may not be materially different from swap partitions during operations.

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

Comment by mitxela 12 hours ago

One traditional reason to prefer a swap partition was that the filesystem driver might have to allocate memory. I think swap files bypass the filesystem driver, though - getting the block extents and then accessing the block device at those locations, instead of accessing the file.

Comment by jenders 1 day ago

Ah the old HN hug. I’ll fix it

Comment by copperx 23 hours ago

What bug?

Comment by zahlman 21 hours ago

"Hug", not bug. Referring to a site (presumably under OP's control) crashing due to increased traffic from HN.

Comment by copperx 21 hours ago

But how are they going to fix the hug?

Comment by LtWorf 13 hours ago

Buying more instances to serve it, I presume.

Comment by wccrawford 21 hours ago

The hug of death.

Comment by SoftTalker 1 day ago

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.

Comment by linsomniac 1 day ago

I have tried to forego swap because I had hoped that it would avoid swap thrashing, where performance goes into the toilet; I'd rather a process was killed but I could still access the system, than be unable to login to it.

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.

Comment by lokar 23 hours ago

Read only pages (most of libraries and binaries) get “paged out” to the file they came from, not swap.

(They obviously don’t page out, they are just discarded and read again when needed)

Comment by anyfoo 23 hours ago

Yes, only dirty (i.e. modified) pages profit from getting paged out to swap.

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.

Comment by lokar 22 hours ago

When we looked it was always tiny

Comment by SoftTalker 23 hours ago

The old rule of thumb used to be 2x actual RAM for your swap file/partition size.

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.

Comment by Sohcahtoa82 22 hours ago

> The old rule of thumb used to be 2x actual RAM for your swap file/partition size.

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.

Comment by al_borland 22 hours ago

This is why they went on to say it doesn’t make sense with modern RAM sizes.

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.

Comment by lotharcable 14 hours ago

Some of that was driven by people wanting hibernation to be reliable.

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.

Comment by lotharcable 14 hours ago

In the distant past there was plenty of times I tried to fix dying web servers by logging in and restarting a rogue process or cleaning up a memory leak... only to have my SSH session and shell sessions being repeatedly killed by OOMs.

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.

Comment by anyfoo 23 hours ago

You never saw any issues, but your systems might have been faster with swap. Even if you're nowhere any threshing threshold, RAM used for caches is better than RAM used for unused pages, which could have been paged out to swapspace.

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.

Comment by lokar 23 hours ago

It does not need it at all. I’ve run a million+ hosts with no swap. You need to be really disciplined about memory allocations (us cgroups) and ok with what happens if you run out (something in that cgroup dies). But there is no “housekeeping “ that requires it.

Comment by anyfoo 23 hours ago

This comes up every time swap is mentioned.

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.

Comment by quectophoton 13 hours ago

Something I've never understood is why, say, 60GB RAM + 4GB swap is supposed to be faster than 64GB RAM + no swap. Or why 64GB RAM + 4GB swap is supposed to be faster than 68GB RAM.

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.

Comment by mitxela 12 hours ago

The actual choice is 32GB RAM + 32GB swap or 32GB RAM + no swap. This is because people already bought their RAM and disks by the time they make the decision, and aren't using the whole disk.

Comment by quectophoton 11 hours ago

I mentioned this in a response[1] to a sibling comment, but my question is more about learning what are the advantages of swap itself, other than just cheaper slow RAM.

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.

[1]: https://news.ycombinator.com/item?id=49670574

Comment by mitxela 10 hours ago

Nothing besides having more of it. Apparently also hibernation, but that's more of an artificial limitation - there's no good reason a system couldn't create a hibernation file on demand.

Comment by anyfoo 13 hours ago

I’m not sure I understand. In your equations, why is swap taking away from RAM? It’s purely additive.

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.

Comment by quectophoton 11 hours ago

In my examples nothing is taking away from nothing, I'm just asking if, if two situations have the same total amount of GB, what's the actual difference between RAM+swap vs entirely RAM.

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.

Comment by anyfoo 6 hours ago

Adding 32GB of RAM is vastly better than adding 32GB of swap, it’s not even close. However, it’s also vastly more expensive. That has always been the case, not just in the current insane situation.

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.

Comment by lokar 22 hours ago

We looked at this a lot (it was a lot of money at our scale). A cgroup itself is just a few small data structures. And a reasonable process inside will only ever have a small amount of dirty memory it won’t ever use. Even then you can’t be sure of it packing neatly into whole pages.

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.

Comment by anyfoo 22 hours ago

Fair enough, you looked and did the math. On my laptop (totally different use case), there is currently plenty of memory in the compressor.

Comment by lokar 22 hours ago

Yeah, personal (desktop/laptop) vs production are totally different. The production workload should be well understood and stable.

Comment by rlpb 1 day ago

It does give you some more RAM for free, as Linux can park allocated but rarely accessed memory and use the freed space for other purposes.

Comment by malwrar 1 day ago

Any tips on measuring the impact of not having swap? I never use it on my machines for similar reasons.

Comment by ktm5j 1 day ago

Worst thing that's ever happened to me is having processes randomly killed by the OOM killer. Could be unpleasant if you're writing an email or document that suddenly disappears because your app got killed.

Comment by mitxela 12 hours ago

The OOM killer usually kills the process that's using the most memory, which is the reason the system is OOM. Sometimes this can be adjusted. When I'm OOM it's almost always because some runaway loop used 50GB and it makes no sense to kill any other process.

If it's killing your email editor then your email editor is bloated or you just need more RAM - or swap.

Comment by anyfoo 23 hours ago

It highly depends on your specific workload, but freeing up RAM by paging out rarely or downright unused pages to swap can definitely give a performance advantage.

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.

Comment by lotharcable 14 hours ago

It just meant that you spent too much on servers. Either that or they could of been doing more.

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.

Comment by ducktective 1 day ago

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?

Comment by dev_hugepages 1 day ago

This is called an oomkiller. The kernel has one but it kicks in very late and the kernel prefers to do page trashing instead of killing processes.

systemd-oomd should be integrated in systemd, you can configure it to your liking and see if it improves your problem.

Comment by SoftTalker 1 day ago

I wish there was an easy way to configure it to say "target user processes first, specifically java (or these days python)" as in my experience they are always the culprits. Processes owned by system accounts or root should be the last ones killed.

Comment by mixmastamyk 4 hours ago

systemd-oomd works reasonably well and there is source code. Perhaps claude can help add more detailed policy support to it.

Just found this comment:

https://news.ycombinator.com/item?id=49663299

Comment by bigstrat2003 17 hours ago

Similarly, in the past I have wished for the ability to exempt a process from the oomkiller. I've run servers where the top memory user was also the server's entire reason for existence, and if that process gets killed the server may as well be down. It would literally have been better for any other process to get killed, but it was always the application process because of the memory usage.

Comment by miladyincontrol 1 day ago

Adding to this, glad systemd-oomd finally added solid rulesets in 261

Made it far easier to target any containers that got too hot rather than ever risk anything higher priority.

Comment by ButlerianJihad 1 day ago

I believe that you mean: https://en.wikipedia.org/wiki/Thrashing_(computer_science)

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

Comment by rovr138 1 day ago

> First off, this is exactly how systemd-oomd is supposed to behave under memory pressure. The documentation is specific on this; systemd-oomd itself says:

> > [...] 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.

Comment by BenjiWiebe 1 day ago

One thing Fedora does now, is use zram.

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.

Comment by MrDrMcCoy 22 hours ago

If it were swap on disk fronted by zswap, it'd be even better ;)

Comment by rwmj 1 day ago

I'm a Fedora developer and I can assure you that Fedora's behaviour when it runs out of memory is still terrible.

Comment by afishhh 1 day ago

Set `/sys/kernel/mm/lru_gen/min_ttl_ms` at boot (see https://docs.kernel.org/admin-guide/mm/multigen_lru.html).

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).

Comment by fc417fc802 1 day ago

> does anyone know why

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?

Comment by wongarsu 1 day ago

Notably windows doesn't use overcommit, and degrades much more gracefully under memory pressure. The biggest tradeoff is the amount of disk space consumed by a page file that also has to reserve space for unused pages that have been allocated but never been swapped in. On linux you can turn overcommit off, but there's too much software written around the assumption that overcommit is on

Comment by fc417fc802 1 day ago

Is that still the case today? Notably (IIUC) overcommit is required for certain security measures. I believe it was chromium that I noticed mmaping somewhere north of 1 TB of memory on startup so that it can do (again IIUC) something akin to ASLR internally.

Comment by wongarsu 1 day ago

On Windows you can achieve something like manual overcommit by calling VirtualAlloc with just MEM_RESERVE. That gives you a continuous space in your process's virtual address space, without actually backing it with any physical pages. Kind of like what a malloc does on linux

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

Comment by fc417fc802 1 day ago

At a glance that seems like a much more sensible design. I guess it's dead in the water for posix on account of fork being CoW? This is quite the rabbit hole. I wonder if programming languages ought to be designed in such a way to accommodate a preemptive signal indicating allocation failure in place of a page fault? Rather than malloc returning null or etc.

Comment by toast0 1 day ago

> I guess it's dead in the water for posix on account of fork being CoW?

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.

Comment by jeroenhd 1 day ago

Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit. Systems with loads of RAM barely lose any storage to swap, but once they do get hit, they can get many gigabytes of swap space without user interaction. I believe macOS does it too, of course.

I'm sure there are many reasons why Linux can't do that by default, but it's a real shame.

Comment by fc417fc802 1 day ago

I assume that's primarily because the stance of most distros would require something like that to be strictly opt-in. I don't know if it's possible to trigger a service based on overall swap usage? But given that the oom killer exists I don't see why it couldn't be trivially repurposed to add swap files on the fly.

Comment by simoncion 22 hours ago

> Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit.

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.

[0] <https://news.ycombinator.com/item?id=49656129>

[1] <https://pqxx.org/development/swapspace/>

Comment by binarin 1 day ago

With some workarounds, I've put chrome and slack into the same RAM-limited cgroup - no more whole system freezes. From my anecdotal evidence, this also answers the question "who should you kill" :)

Comment by PunchyHamster 22 hours ago

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

Comment by negrel 1 day ago

OS are designed to fully exploit available resources, Linux tries its best before triggering an OOM kill.

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.

Comment by oomedfornight 1 day ago

A strange behavior I sometimes run into with earlyoom is that I try to start up some buggy software of mine and it seemingly never starts.

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

Comment by CoastalCoder 1 day ago

Just mentioning this in case it's helpful:

If you know ahead of time which programs / processes are at risk of unacceptably high memory usage, check out "ulimit".

Comment by joshAg 1 day ago

Don't worry, it's not just you: https://lkml.org/lkml/2019/8/4/15

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.

Comment by throw0101d 1 day ago

> It's because linux is a toy OS. Specifically, it overcommits memory

…by default. It can be disabled via a sysctl:

* https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

Comment by joshAg 1 day ago

You're right. I'm glad the very next sentence in my comment landed.

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

Comment by 1 day ago

Comment by TimTheTinker 1 day ago

Illumos also doesn't overcommit, if you want the more modern OS descended from Solaris.

Comment by joshAg 23 hours ago

can't believe i forgot to mention them! Updating the parent for visibility

Comment by nicman23 1 day ago

or use the system's oom ?

Comment by joshAg 1 day ago

That's what's breaking the system and causing freezes. You can tune it a bit to minimize when it happens, but not get rid of the issue entirely.

Comment by rwmj 1 day ago

All I want is the oomkiller to always kill firefox. Somehow that's very difficult to achieve.

Comment by lokar 23 hours ago

The oom killer is a monkey with a gun. It’s a last resort when you were going to crash (or worse, hang) anyway.

You should have a much better “plan A” to avoid this situation.

Comment by SoftTalker 1 day ago

... which then kills sshd, locking you out of being able to get in and do any recovery.

Comment by nicman23 1 day ago

the system will restart sshd?

Comment by joshAg 1 day ago

the system will kill whatever it damn well pleases. You can tune it with priorities to ask it to try to not kill that, and once it kills your sshd once, you'll probably configure it to exempt sshd from being OOM killed at all. That doesn't fix the memory pressure or hanging or stalling, but you'll at least be able to log into the box still instead of dragging out a serial cable.

Comment by BoredomIsFun 1 day ago

It does not if you switch swapp off and use zram instead. I am typing right now on such a setup wityh 16 GiB ram and it occasionally, once a week or so, kills my firefox due to oom.

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.

Comment by cassianoleal 1 day ago

> switch swapp off and use zram instead

Or zswap instead of zram.

https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-...

https://linuxblog.io/zswap-better-than-zram/

Comment by Narishma 23 hours ago

Linux and the software running on it are generally very bad at handling out-of-memory situations.

Comment by trompetenaccoun 1 day ago

This has finally been fixed in the latest Ubuntu version (26), it now force closes the culprit.

Comment by jillesvangurp 1 day ago

Ah nice. I was dealing with that in one of our environments where a security update ended up causing apt to use more memory than usual so the oom killer nuked our elasticsearch process to "free up some memory".

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.

Comment by noisem4ker 11 hours ago

I couldn't find any information about that. Do you have something to back it up (news articles, changelog entries), or was it just your subjective experience?

Comment by dagenix 1 day ago

How did they fix it?

Comment by elektrontamer 1 day ago

I always install earlyoom for that reason

Comment by PunchyHamster 22 hours ago

It should eventually kill it. But having swap means it will try to use it as RAM which might delay/freeze system hard

Comment by pestatije 1 day ago

not tangential at all...try setting up a swap partition

Comment by jenders 1 day ago

[flagged]

Comment by pndc 1 day ago

I had a 1GB Debian VM which started freezing (requiring a hard reboot) after a routine aptitude upgrade to apply security patches. It was indeed caused by low memory, but not out of memory as there was still enough swap space remaining.

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.

Comment by kazinator 1 day ago

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.

Comment by 1 day ago

Comment by spijdar 1 day ago

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] >

Comment by genxy 22 hours ago

Are you running Sprite in qemu or on hardware?

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.

Comment by spijdar 21 hours ago

Both!

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...)

[0] https://github.com/phabrics/nme

Comment by jenders 19 hours ago

I love this kind of stuff. Great share

Comment by williebeek 1 day ago

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.

Comment by blablabla123 1 day ago

On the Desktop fine-grained partitioning is a bit questionable but on a server it's still quite practical. E.g. preventing the database or excessive logs from filling the disk space. The latter is also an attack vector actually.

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.

Comment by MayeulC 1 day ago

I tried that a few years ago. The result was worse than swapping. The kernel really tries its best not to kill anything, and you end up with "thrashing" again, where code pages (shared objects, executables, mmaped files) are evicted and need to be loaded again from disk. In practice the slowdown was worse than swapping to disk, and much more sudden. I'd recommend at least zram to soften the OOM landing.

Comment by tacomagick 1 day ago

Id always suggest at least 2-4G of swap even if you have plenty of memory 32g+ because for that rare edge case where you'd really not want to OOM.

Comment by ChocolateGod 23 hours ago

Yep. Swap + zswap + earlyoom is a great safety need incase things get hairy.

Comment by spudlyo 1 day ago

> For swap, the best advice is to disable swap on your desktop, unless <8GB 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.

Comment by jenders 1 day ago

Agreed. Buy more RAM but these days that means taking a HELOC

Comment by pyreko 1 day ago

> you probably won't either

Hibernation?

Comment by crabbone 1 day ago

I'm not sure if that's a bad choice... BTW, I think STIG still requires it. So, if you want to be compliant with some (US) government requirements, you'd still have to put different bits of your system on different partitions / devices.

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.

Comment by greedo 1 day ago

There are also controls that specify noexec, nodev etc for filesystems.

Comment by Kim_Bruning 1 day ago

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?

Comment by chuckadams 1 day ago

> Is it a rule that everything starting with a 'z' must be cool?

They tend to be the last word on the subject :)

Comment by optionalsquid 1 day ago

It also doesn't sound like a particularly good idea on BTRFS, judging by the linked documentation:

https://btrfs.readthedocs.io/en/latest/Swapfile.html

Comment by fc417fc802 1 day ago

And since you should probably be running a modern CoW filesystem then you probably shouldn't be using swapfiles ... is the conclusion I arrived at anyway. Either install multiple times more RAM than you need and enable zswap or else set aside a swap partition as has always been done.

Comment by jenders 1 day ago

Truth be told—- I don’t use swap and set `vm.swappiness=0` but in these difficult times, swap may be the hero we need.

Comment by jeroenhd 1 day ago

Swapfiles on BTRFS seem to work great if you allocate them early (with the command linked in your article) and put them in a different subvolume than the rest of your system.

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.

Comment by cesarb 4 hours ago

> 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,

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).

Comment by jck86 1 day ago

zswap indeed is the real magic almost silver bullet nowadays. Device backed swap is often not needed anymore and it solves a lot of the issues with freezing under memory pressure, though it may not be ideal for servers.

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.

Comment by jenders 1 day ago

That’s a good call out. I’ve never used ZFS on root. Been a ZFS user on Linux since the FUSE days but it has never seemed particular well suited (O_DIRECT support came late, ARC/page cache redundancy, etc). I can’t guarantee a consistent enough workload to optimize ZFS for and I don’t feel like it’s general purpose enough. Large object storage though? I’m sitting on a PB of ZFS.

Comment by 1 day ago

Comment by cfstras 1 day ago

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.

Comment by MBCook 1 day ago

Does contiguousness matter these days? Especially since all disk locations are lies anyway as SSD firmware has its own layer of indirection too?

Comment by jenders 1 day ago

If you want to share step-by-step, I’ll update the gist.

Comment by cfstras 1 day ago

That’s my point, it’s different for each distro & partitioning setup, so I wouldn’t know what to share here. Having a swap partition makes it as easy as adding `resume=/dev/sdXYZ` or `resume=UUID=…` to your kernel parameters.

Comment by simoncion 1 day ago

And using LVM for "partitioning" bypasses a lot of this silliness. Do 'lvcreate --contiguous' and you should be good to go if you're using most any non-toy initrd.

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.

Comment by meitham 14 hours ago

This is true on ext4 but don’t use swapfile with ZFS or btrfs fs.

Comment by holowoodman 1 day ago

Stop using partitions. Use LVM!

Comment by Kim_Bruning 1 day ago

Stop using LVM. Use ZFS!

(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. )

Comment by jenders 1 day ago

Not a btrfs user but OpenZFS u til recently didn’t even support O_DIRECT and may still duplicate page cache in arc. It’s not well suited as a general purpose FS where you can’t anticipate the workload, like on a desktop.

Comment by p_l 1 day ago

O_DIRECT is niche use case (originally called rather unkind words when it got copied from Irix to Linux).

Page cache duplication has been greatly lowered in last decade

Comment by zbentley 1 day ago

Anecdotal, but I've been happily using it under Linux desktops for years, and it works quite well. Workloads include: development, VM hosting, steam gaming, web browsing, multimedia playback. OSes include Debian, Proxmox, vanilla Arch, CachyOS, and others. Daily-driver hardware (ignoring servers and less general-purpose desktop stuff) included 2019 chromeboxes, 2015 (!) laptops, current-gen gaming laptops, and desktop towers with handfuls of spinning rust and solid state drives.

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.

Comment by rascul 1 day ago

I'll consider it when zfs in in tree.

Comment by holowoodman 1 day ago

ZFS is overrated and mostly a hobbyist/enthusiast thing.

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.

Comment by jenders 1 day ago

>> ZFS is overrated and mostly a hobbyist/enthusiast thing.

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.

Comment by throw0101d 1 day ago

> ZFS is overrated and mostly a hobbyist/enthusiast thing.

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.

Comment by jenders 1 day ago

How often are you needing to change partition geometry after install, on a server?

Comment by holowoodman 1 day ago

Depends. Some customers do run a lot of "pets, not cattle" servers, and those can get a few extra hard disks if space runs out. Some security guidelines prescribe separate volumes/filesystems for e.g. /home or /var/log, so log spam doesn't kill the whole system as easily. But of course, this means that sometimes the initial sizes aren't right and you need to extend something. In those cases, which happen a few times per year, not using LVM would be a huge problem.

But even for the "frequently reinstalled cattle"-usecase, LVM has benefits, e.g. snapshots for backups, debugging and forensics.

Comment by simoncion 1 day ago

My short answer is "Not frequently, but when I do, I'd be very angry about having to screw around repartitioning a disk instead of fiddling with an LV, VG, or some PVs.".

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

Comment by greedo 1 day ago

LVM for a *nix sysadmin is cheat mode for managing storage.

Comment by kiln_ash 1 day ago

systemd-oomd killing your whole session because Fedora enrolled user@.service is nasty. A swap file won't save you from the OOM killer, just delays it.

Comment by cryptonector 23 hours ago

But first it makes your system slow.

Comment by dogline 23 hours ago

Well, this post made me reassess using zswap vs zram. I've expanded my zswap and disabled zram. Not sure if that makes any difference to others, but it's probably good for me.

Comment by mdspan 3 days ago

Swap files are also much easier to set up than partitions if you're using full disk encryption.

Comment by demomode 1 day ago

Swap files are very fragile if you are using hibernation. For FDE I prefer LVM-over-LUKS and a dedicate partition

Comment by pasc1878 1 day ago

MacOS seems to have no problem with hibernating and it and its predecessor NeXT have been using swap files for over 30 years.

Comment by killerstorm 1 day ago

MacOS has no problem with hibernation because hardware and software are designed together: it uses TPM to manage swap encryption. I assume "BIOS" is also optimized to enable fast boot on sleep.

Linux can work with TPM but it's never as smooth. (Unless I guess you make it custom for your specific setup.)

Comment by jeroenhd 1 day ago

These days with cryptenroll and friends, using the TPM is hardly an issue anymore. LVM and swapfiles both work well if you just create one large "everything but EFI" encrypted volume.

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.

Comment by cedilla 1 day ago

I have FDE with keys in the TPM. It's pretty smooth bit required a one time additional step in Fedora. It's also probably not very secure, but my threat model is simple theft.

Comment by avhception 1 day ago

What's the benefit of using the TPM compared to a simple passphrase at boot, in that scenario?

Comment by theblazehen 1 day ago

A person wouldn't be able to pull the disk to get at the information

Comment by gertop 1 day ago

Windows has no problem with hibernation and FDE and it uses a swap file.

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.

Comment by somat 1 day ago

For what it's worth(not much) On OpenBSD swap is always encrypted, With or without full-disk encryption. I don't know why linux always has to make the easy things hard.

Comment by fc417fc802 1 day ago

How so? It's a one time setup procedure of only a few steps to create a tiny "protective" ext4 (or whatever) partition at the front. Thereafter you configure crypttab to mount the partition via UUID with an offset and key. If you don't need to hibernate you can read the key from /dev/urandom.

Comment by tarruda 1 day ago

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.

Comment by mindwok 1 day ago

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.

Comment by topaz0 1 day ago

Swapfiles are fixed size just like swap partitions. They do not grow and shrink arbitrarily as you swap more/less.

Comment by mindwok 18 hours ago

Oh I see so they’re reserved space regardless. That makes sense !

Comment by koala_man 1 day ago

> 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."

Comment by Aurornis 1 day ago

> hen I benchmarked it on a (spinning rust) HDD

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.

Comment by 1 day ago

Comment by jenders 22 hours ago

+1. This test and its conclusions are flawed. See CAV/CLV

Comment by dwedge 1 day ago

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

Comment by WalterGR 1 day ago

In practice, there’s a potentially tremendous impact if you’re using a spinning metal disk. Sectors at the beginning of the disk (which is at the outer edge) are read/written way faster than sectors at the end. File systems tend to prefer writing files at the beginning. If the file system has been used for ‘a long time’ then it’s either fragmented - or it’s been defragmented and the free space is at the slow end of the drive.

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.)

Comment by gblargg 1 day ago

Indeed. I'd always put swap near the beginning, then a small root partition, then the rest. This reduced head movement for often-accessed data, and used the higher bandwidth of the outer tracks.

Comment by HackerThemAll 21 hours ago

Why do I still need swap space at all, be it a swap file or swap partition? I have 64GB of RAM and I don't overprovision it.

WHY DO I HAVE TO CONSIDER SWAP in 2026?

Comment by jenders 18 hours ago

Swap is not recommended on servers where responsiveness and determinism are more important than failure recovery of any one server.

Comment by thyrsus 1 day ago

Most file systems get cached in ram, which is unlikely to have happy consequences when scarce ram triggers use of the filesystem swap.

Comment by Sohcahtoa82 22 hours ago

Are there people still using swap partitions? I've been using swap files on Linux for years now.

Comment by jenders 22 hours ago

you love to see it

Comment by mcculley 1 day ago

It would be nice if the VFS had a hook for providing swap pages, making this manual futzing less necessary.

Comment by aidenn0 20 hours ago

Not all filesystems support swap files.

Comment by gbraad 12 hours ago

.. and often the only solution for a VM/hosted machine. It gives you a flexibility you otherwise not have, expand/shrink when needed; a partition is static/fixed in place. Often used them, and still do; `dd of=/swapfile if/dev/zero bs=1M count=1024`/`mkswap`, and `swapon`.

Comment by lloydatkinson 23 hours ago

I've always thought it a bizarre and unusual "requirement" that swap gets an entire partition. Windows has it as a file too. At least with this approach, if you change the amount of RAM in your computer, you don't need to go resize the swap partition if you want them to match.

Comment by Toynbeeidea 1 day ago

No.

Comment by crabbone 1 day ago

Oh, the irony of:

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

If we are going full modern, why not create a Systemd unit? ( https://www.freedesktop.org/software/systemd/man/latest/syst... ) if you need more info. If you didn't know this: /etc/fstab is not used directly after the pivot. Systemd parses it, creates units for every record in it, and that's what gets executed in reality. I can't imagine why would you want a swap file before pivot.

Comment by jenders 1 day ago

[flagged]

Comment by delta_p_delta_x 12 hours ago

This single comment of yours has in my eyes made your entire post worthless.

SystemD has single-handedly consolidated and streamlined Linux administration. I think valid criticism is useful, but calling it malware is a non-sequitur.

Comment by SahAssar 1 day ago

If you are going to make recommendations and promote them to a wide community (linux users) that is predominantly using something that you do not consider advisable for that recommendation (systemd) then it might be good to mention that.

Systemd is probably on 80%+ linux systems that people interact with, and 95%+ that people manually configure.

Comment by nicman23 1 day ago

i cannot hibernate in a swapfile in zfs

Comment by throwawaypath 20 hours ago

Swap is disabled everywhere. Endpoint hardening.

Comment by monster_truck 1 day ago

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.

Comment by PunchyHamster 22 hours ago

I love how there is no explanation why, or any info why wasting 2GB as partition is any different than as file

Comment by jenders 18 hours ago

This is a mechanism post not a policy post. If you want to see my take on swap, see my last response on that gift.

Comment by lightedman 1 day ago

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.

Comment by jenders 18 hours ago

I’m not advocating for anything but for distros to stop recommending swap partitions. I advocate for right-sizing your hardware to predicable workloads and not using swap at all. On your pet servers or desktops where the workload is experimental or wildly unpredictable, swap files make more sense over partitions.

Comment by lightedman 2 hours ago

"I advocate for right-sizing your hardware to predicable workloads and not using swap at all."

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.

Comment by waynesonfire 1 day ago

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.

Comment by jenders 23 hours ago

What subsystem are you referring to?

Comment by charcircuit 1 day ago

Linux distros that do use swap files do so statically. It doesn't handle dynamically growing and shrinking it like other operating systems.