[dead]
A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
61–70 of 137 posts
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#62Earlier quoted context omitted.
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.
ZFS /tmp is probably fine, but swapping to ZFS on Linux is dicey AIUI; there's an unfortunate possibility of deadlock https://github.com/openzfs/zfs/issues/7734
Ah, thanks for pointing that out - wasn't aware.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#63[deleted]
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#64As someone who sort of needs to juice all my ram, this is annoying but at least it can be turned off.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#65The part that's more likely to bite people here and that's easily overlooked is that files in /var/tmp will survive a reboot but they'll still be automatically deleted after 30 days.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#66I'm surprised to discover that it was not already the case for a long time for tmpfs to be used for /tmp, and that change is nice. But the auto-cleanup feature looks awful to me. Be it desktop or servers, machine with uptime of more than a year, I never saw the case of tmp being filled just by forgotten garbage. Only sometimes filled by unzipping a too big file or something like that. But it is on the spot. It used t…
I tried out variations on this on my daily driver setups. The design choices here were likely threefold: Store tmpfs in memory: volatile but limited to free ram or swap, and that writes to disk Store tmpfs on dedicated volume: Since we're going to write onto disk anyway, make it a lightweight special purpose file system that's commited to disk On disk tmpfs but cleaned up periodically: additional settings to clean up…
A tmpfs itself is basically a ramdisk by definition. I assume you mean /tmp when you say tmpfs?
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#67The 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.
Fedora did this long before debian. I remember doing wget of an .iso file on /tmp and my entire wayland session being killed by the OOM killer.
I still think it's a terrible idea.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#68The 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.
Fedora did this long before debian. I remember doing wget of an .iso file on /tmp and my entire wayland session being killed by the OOM killer. I still think it's a terrible idea.
Use `/var/tmp` of you want a disk backed tmp.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#69Earlier quoted context omitted.
I'm with you. I don't swap. Processes die. OOM. Linux can recover and not lose data. Just unavailable for a moment.
The Linux OOM killer is kinda sketchy to rely on. It likes to freeze up your system for long periods of time as it works out how to resolve the issue. Then it starts killing random PIDs to try to reclaim RAM like a system wide russian roulette. It's especially janky when you don't have swap. I've found adding a small swap file of ~500 MB makes it work so much better, even for systems with half a terabyte of RAM this…
Install earlyoom or one of its near-equivalents. That mostly solves the problem of it freezing up the system for long periods of time.
I haven't personally seen the OOM killer kill unproductively - usually it kills either a runaway culprit or something that will actually free up enough space to help.
For your "even for systems with half a terabyte of RAM", it is logical that the larger the system, the worse this behaviour is, because when things go sideways there is a lot more stuff to sort out and that takes longer. My work server has 1.5TB of RAM, and an OOM event before I installed earlyoom was not pretty at all.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#70We did this song and dance in RHEL. It's fine. Just use /var/tmp if you need persistent tmp storage. Gnome and X and tmux will not make you swap and if they do run xfce instead.