i cannot hibernate in a swapfile in zfs
Stop making swap partitions—use swap files instead
81–90 of 256 posts
Re: Stop making swap partitions—use swap files instead
#82Tangential, 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?
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,…
or use the system's oom ?
Re: Stop making swap partitions—use swap files instead
#83Tangential, 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?
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.
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.
Re: Stop making swap partitions—use swap files instead
#84Earlier quoted context omitted.
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,…
or use the system's oom ?
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.
Re: Stop making swap partitions—use swap files instead
#85Yeah, 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.
Re: Stop making swap partitions—use swap files instead
#86Use 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]Re: Stop making swap partitions—use swap files instead
#87Remember 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.
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.
Re: Stop making swap partitions—use swap files instead
#88Earlier quoted context omitted.
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,…
or use the system's oom ?
... which then kills sshd, locking you out of being able to get in and do any recovery.
Re: Stop making swap partitions—use swap files instead
#89Earlier quoted context omitted.
MacOS seems to have no problem with hibernating and it and its predecessor NeXT have been using swap files for over 30 years.
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.)
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.
Re: Stop making swap partitions—use swap files instead
#90Tangential, 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?
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.
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.