The third mitigating feature the article forgot to mention is that tmpfs can get paged out to the swap partition. If you drop a large file there and forget it, it will all end up in the swap partition if applications are demanding more memory.
buckle8017 · 1h ago
Which is a great reason to have a big swap file now.
gnyman · 36m ago
Note though that if you don't have swap now, and enable it, you introduce the risk of thrashing [1]
If you have swap already it doesn't matter, but I've encountered enough thrashing that I now disable swap on almost all servers I work with.
It's rare but when it happens the server usually becomes completely unresponsive, so you have to hard reset it.
I'd rather that the application trying to use too much memory is killed by the oom manager and I can ssh in and fix that.
Disabling swap on servers is de-facto standard for serious deployments.
The swap story needs a serious upgrade. I think /tmp in memory is a great idea, but I also think that particular /tmp needs a swap support (ideally with compression, ZSWAP), but not the main system.
ravetcofx · 6m ago
Swap always seemed more meant for desktop use. Servers you need to give the real memory expected of the application stack.
baq · 24m ago
This is why I’m running with overcommit 2 and a different ratio per server purpose.
…though I’m not sure why we have to think about this in 2025 at all.
fh973 · 24m ago
Swap on servers somewhat defeats the purpose of ECC memory: your program state is now subject to complex IO path that is not end-to-end checksum protected.
Also you get unpredictable performance.
So typically: swap off on servers. Do they have a server story?
abrookewood · 11m ago
That's a really good point that had never occurred to me.
Edit: I think that the use of ZFS for your /tmp would solve this. You get Error Corrected memory writing to an check-summed file system.
GCUMstlyHarmls · 2h ago
Actually quite handy and practical to know about, specifically in the context of a "low end box" where I personally would prefer that RAM exist for my applications and am totally fine with `/tmp` tasks being a bit slow (lets be real, the whole box is "slow" anyway and slow here is some factor of "vm block device on an ssd" rather than 1990s spinning rust).
palmfacehn · 2h ago
If I am satisfied with my disk speed, why would I want to use system memory? What are the specific use cases where this is warranted?
margalabargala · 1h ago
Computers like a Raspberry Pi, where the OS is on a sdcard, will hugely benefit.
jauntywundrkind · 1h ago
Yup. There's lots of advice about how to reduce cycle count, increase lifetime of sd cards out there. This post has a bunch of ideas, and tmpfs is definitely on the list. https://raspberrypi.stackexchange.com/a/186/32611
techjamie · 1h ago
Technically it'll have some impact on the number of write cycles your disk goes through, and marginally reduce the level of wear.
Most disks have a lot of write cycles available that you'll be fine anyway, but it's a tiny benefit.
Incipient · 37m ago
Using the example from the article, extracting an archive. Surely that use case is entity not possible using in-memory? What happens if you're dealing with a not-unreasonable 100gb archive?
Who runs around with 100gb+ of swap?!
perlgeek · 27m ago
Who runs around with a 100gb+ /tmp partition?
Our default server images come with a 4.4GB /tmp partition...
gigatexal · 30m ago
Why this change? Writing to it will be faster than disk but idk if am is a precious commodity I’d rather it was just a part of the disk I was writing to.
ComputerGuru · 1h ago
I feel like this is mixing agendas. Is the goal freeing up /temp more regularly (so you don’t inadvertently rely on it, to save space, etc) or is the goal performance? I feel like with modern nvme (or just ssd) the argument for tmpfs out of the box is a hard one to make, and if you’re under special circumstances where it matters (eg you actually need ram speeds or are running on an SD or eMMC) then you would know to use a tmpfs yourself.
(Also, sorry but this article absolutely does not constitute a “deep dive” into anything.)
ars · 1h ago
File is tmpfs will swap out if your system is under memory pressure.
If that happens, reading the file back is DRAMATICALLY slower than if you had just stored the file on disk in the first place.
This change is not going to speed things up for most users, it will slow things. Instead of caching important files, you waste memory on useless temporary files. Then the system swaps it out, so you can get cache back, and then it's really slow to read back.
This change is a mistake.
saurik · 1h ago
Why is reading the data back from swap be slower at all -- much less "DRAMATICALLY" so -- than saving the data to disk and reading it back?
cwillu · 1h ago
Because swapping back in happens 4kb at a time
imp0cat · 1h ago
Most systems probably aren't having problems with insufficient RAM nowaday though, do they? And this will reduce wear on your SSD.
If you're running it in a VM you might not have all that luxurious RAM.
When my Linux VM starts swapping I have to either wait an hour or more to regain control, or just hard restart the VM.
imp0cat · 22m ago
Right, but if it's a VM, it's probably provisioned by something like ansible/terraform? If so, it's quite easy to add an init script that will disable this feature and never have to worry about it again.
renewiltord · 1h ago
Why is there no write through unionfs in Linux? Feels like a very useful tool to have. Does no one else need this? Have half a mind to write one with an NFS interface.
EDIT: Thank you, jaunty. But all of these are device level. Even bcachefs was block device level. It doesn't allow union over a FUSE FS etc. It seems strange to not have it at the filesystem level.
If you have swap already it doesn't matter, but I've encountered enough thrashing that I now disable swap on almost all servers I work with.
It's rare but when it happens the server usually becomes completely unresponsive, so you have to hard reset it. I'd rather that the application trying to use too much memory is killed by the oom manager and I can ssh in and fix that.
[1] https://docs.redhat.com/en/documentation/red_hat_enterprise_...
The swap story needs a serious upgrade. I think /tmp in memory is a great idea, but I also think that particular /tmp needs a swap support (ideally with compression, ZSWAP), but not the main system.
…though I’m not sure why we have to think about this in 2025 at all.
So typically: swap off on servers. Do they have a server story?
Edit: I think that the use of ZFS for your /tmp would solve this. You get Error Corrected memory writing to an check-summed file system.
Most disks have a lot of write cycles available that you'll be fine anyway, but it's a tiny benefit.
Who runs around with 100gb+ of swap?!
Our default server images come with a 4.4GB /tmp partition...
(Also, sorry but this article absolutely does not constitute a “deep dive” into anything.)
If that happens, reading the file back is DRAMATICALLY slower than if you had just stored the file on disk in the first place.
This change is not going to speed things up for most users, it will slow things. Instead of caching important files, you waste memory on useless temporary files. Then the system swaps it out, so you can get cache back, and then it's really slow to read back.
This change is a mistake.
Also, you can easily disable it: https://www.debian.org/releases/trixie/release-notes/issues....
When my Linux VM starts swapping I have to either wait an hour or more to regain control, or just hard restart the VM.
EDIT: Thank you, jaunty. But all of these are device level. Even bcachefs was block device level. It doesn't allow union over a FUSE FS etc. It seems strange to not have it at the filesystem level.