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.
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?
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).
> 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.
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.
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?
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
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
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.
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.
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)
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.
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.
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
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.)
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.
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.
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.)
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.
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.
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.
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?
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).
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...
> > [...] 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.
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.
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?
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
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.
If you know ahead of time which programs / processes are at risk of unacceptably high memory usage, check out "ulimit".
Meanwhile zswap (of no relation with zfs) is free performance. Is it a rule that everything starting with a 'z' must be cool?
https://btrfs.readthedocs.io/en/latest/Swapfile.html
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.)
Linux can work with TPM but it's never as smooth. (Unless I guess you make it custom for your specific setup.)
But even for the "frequently reinstalled cattle"-usecase, LVM has benefits, e.g. snapshots for backups, debugging and forensics.