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.
ducktective 31 minutes 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?
afishhh 4 minutes ago [-]
[delayed]
dev_hugepages 27 minutes 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.
> 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.
negrel 24 minutes 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:
The README contains a lot of interesting information.
CoastalCoder 9 minutes 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".
elektrontamer 29 minutes ago [-]
I always install earlyoom for that reason
cfstras 29 minutes 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.
Kim_Bruning 1 hours 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?
39 minutes ago [-]
dwedge 2 hours 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
WalterGR 2 hours 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.)
gblargg 1 hours 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.
holowoodman 1 hours ago [-]
Stop using partitions. Use LVM!
mdspan 2 days ago [-]
Swap files are also much easier to set up than partitions if you're using full disk encryption.
demomode 2 hours ago [-]
Swap files are very fragile if you are using hibernation. For FDE I prefer LVM-over-LUKS and a dedicate partition
pasc1878 58 minutes ago [-]
MacOS seems to have no problem with hibernating and it and its predecessor NeXT have been using swap files for over 30 years.
killerstorm 16 minutes 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.)
charcircuit 2 hours ago [-]
Linux distros that do use swap files do so statically. It doesn't handle dynamically growing and shrinking it like other operating systems.
0xbadcafebee 2 hours ago [-]
Unless you use the Linux package that does manage swap files dynamically.
Rendered at 09:20:13 GMT+0000 (Coordinated Universal Time) with Vercel.
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?
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.
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.
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?
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.)