Posted by speckx 20 hours ago
Only in Linux - Windows has no problem with swap in a file. Swap partition is an awful idea because you cannot easily resize it.
Zram is also a bad idea, when it is filled, the system starts swapping to a disk, and old pages nobody needs are kept in RAM forever. Zswap is better in this aspect - old pages are pushed to the disk and newer ones kept in memory. But Linux distributions use zram by default.
Also, it seems that many distributions now place /tmp in RAM (tmpfs). Whoever made such decision is not very bright. When you place a large file in /tmp (for example, viewing a large compressed archive which is automatically unpacked into a temporary location), it fills the memory and the systems locks up completely, including mouse and GUI - because bright people developing Linux cannot think of reserving resources for desktop environment to prevent exactly this situation. Why reserve memory for GUI? Obviously files placed into /tmp are more important. Who needs GUI nowadays when you can easily connect over SSH from another machine and kill the misbehaving program.
If you are making a Linux distribution, do not place /tmp into memory. Or at least check how much RAM user has, and add a limit on tmpfs after which files are pushed onto the disk. Also, do reserve memory for window manager with high priority.
That's why I don't use swap.
For example: you have a background program that you're not using and in the foreground you're crunching data from disk. In this scenario the most efficient use of your memory is to swap the background program out and pull the disk data into RAM.
Then comes the challenge of deciding what processes/data to free or page, whether that's flagged by the system as it's running or at coding/compile time. And that seems similar to the issue of picking a swap strategy for a distro/OS, which will depend on the user's demands or system, setting a good default and exposing how to change the configuration to a better match if needed.
Shuffling out 8GB with a spinning hard drive could take a full minute…
That said, I agree with you. I’d rather not use swap unless absolutely necessary and I don’t want the latter to happen either…
Plus, I don’t want my storage in the “critical path” of memory accesses, even if rare.
I was expecting some problems with my switch to NixOS back in June, but it's been just superb. Even things like building deb packages for my Ubuntu 26.04 machines at work have not been a problem at all.
I had dabbled with NixOS for a year or two before making the switch and had some familiarity with the nixlang and various concepts (SOPS, age, flakes). But, what really smoothed out the switch was using Claude Code to develop the NixOS configs. Everything is easy to do that way, and any issues are easy to back out.
You can build your entire system from a worktree and merge if it works or boot the old generation if it doesn't. This is great for trialing new kernels, NixOS releases, or alternate Window managers, and rolling back is trivial.
One downside is that there is only one stable NixOS at a time, and no LTS. However in practice I haven't found this to be an issue across multiple desktops, servers and SBCs.
I had planned to upgrade the machine to 32GB of RAM but I don't really feel it's necessary at this point. Which is obviously great given the current RAM costs!
> filesystem - must be only single device
> This means swapfiles will have an amplified impact, much larger than the size of the swapfile itself.
> Users should be aware of the impact when using swapfiles alongside other data. This is especially discouraged for root filesystem.
If a swap file is the only thing that will work with your setup, then it's fine to use one, but if you're at all able to use a swap partition, then that's a far better choice. (Swap files are fine on ext4 and xfs; it's only COW filesystems like btrfs and zfs where they should be avoided.)
Then again, I mostly use XFS, which has no data checksums at all, so YMMV.
if your intention is to have enough compressed ram such that you never reach the limit (compression ratios are usually around 3 with zstd) you can allocate over 100% of your ram in zram. then have 100% of your ram as a swap partition for hibernation. this works extremely well but should you exhaust your zram swap serious problems may begin.
zswap will be using your SSD and putting wear on it and also imposing latency spikes on old page access, only makes sense if you are certain your swap usage may spike too high in my opinion.