Live data from Hacker News

Stop making swap partitions—use swap files instead

gist.github.com

91–100 of 257 posts

Re: Stop making swap partitions—use swap files instead

#91
post #80

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?

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

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

Re: Stop making swap partitions—use swap files instead

#92

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?

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

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

Re: Stop making swap partitions—use swap files instead

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

Re: Stop making swap partitions—use swap files instead

#94
post #86

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]

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.

Re: Stop making swap partitions—use swap files instead

#95

Earlier quoted context omitted.

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…

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 spott…

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

Re: Stop making swap partitions—use swap files instead

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

Re: Stop making swap partitions—use swap files instead

#97

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.

> you probably won't either

Hibernation?

Re: Stop making swap partitions—use swap files instead

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

Re: Stop making swap partitions—use swap files instead

#99
post #52

Earlier quoted context omitted.

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…

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.

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.

Re: Stop making swap partitions—use swap files instead

#100
post #96

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.

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