I thought /dev/shm was ramdisk?
Does /dev/shm stay? Surely it does but it is also capped at 50% RAM. Does that mean /dev/shm + /tmp can now get to 100% RAM? Or do they share the same ram budget?
A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
101–110 of 137 posts
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#102Earlier quoted context omitted.
Sure, but note that your usecase goes specifically against fhs and posix specs: >Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. >Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch…
Programs shouldn't assume that about /tmp, the user advising this is fine.
The user wasn't "advising" this, or asking if it was fine. They're just doing it. Everything that they want to do with their own computer is permissible.
The person you're replying to is saying that tmp is meant for temporary storage that could disappear between reboots. A permanent archive of the past states of the tmp directory is not temporary.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#103Earlier quoted context omitted.
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 beha…
it's anecdata but I've had the linux OOM Killer take out OVS (Open Virtual Switch) on a kubernetes node several times. Made me really not mind having a little swap space setup just in case.
OOMKiller, as far as I understand it, will just pick a random page, figure out who owns it, and then kill that process, repeating until enough memory is available. This will bias toward processes with larger memory allocations, but may kill any process.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#104Swap 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?
The purpose of ECC has nothing to do with being "end-to-end". A typical CPU path to/from DRAM will not be end-to-end either, since caches will use different encodings. This is generally considered fine since each I/O segment has error detection in one form or another, both in the CPU-to-memory case and the memory-to-disk case. ECC in general is not like cryptographic authentication where it protects against any possible alteration; it's probabilistic in nature against the most common failure modes.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#105Earlier quoted context omitted.
it's anecdata but I've had the linux OOM Killer take out OVS (Open Virtual Switch) on a kubernetes node several times. Made me really not mind having a little swap space setup just in case.
OOMKiller, as far as I understand it, will just pick a random page, figure out who owns it, and then kill that process, repeating until enough memory is available. This will bias toward processes with larger memory allocations, but may kill any process.
> If it ever becomes necessary for the OOM Killer to kill processes, the decision of which processes to kill will be made based on something called the OOM score. Each process has an OOM score associated with it.
> Every running process in Linux has an OOM score. The operating system calculates the OOM score for a process, based on several criteria - the criteria are mainly influenced by the amount of memory the process is using. Typically, the OOM score varies between -1000 and 1000. When the OOM Killer needs to kill a process, again, due to the system running low on memory, the process with the highest OOM score will be killed first!
https://learn.redhat.com/t5/Platform-Linux/Out-of-Memory-Kil...
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#106Earlier quoted context omitted.
It only became the default on Fedora and other Linux distros following systemd because it was the default in systemd. It was a bad idea on Solaris too, but at least back in those days the trade-off between RAM and disk storage was very different from today now we have NVME drives and such.
Oh no, tmpfs was introduced and used way before systemd.
Which was contested by no-one. He complained about systemd switching /tmp to tmpfs, not systemd people making or causing tmpfs in general.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#107Earlier quoted context omitted.
Because swapping back in happens 4kb at a time
It's also because a filesystem is much more likely to have consecutive parts of a file stored consecutively on disc, whereas swap is going to just randomly scatter 4kB blocks everywhere, so you'll be dealing with random access read speed instead of throughput read speed.
Valid argument with FAT on spinning rust, invalid with ext4 on ssd. ext4 is extent-based so the fragmentation overhead doesn't happen.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#108Earlier quoted context omitted.
Use `/var/tmp` of you want a disk backed tmp.
I thought /var/tmp is for applications while /tmp is for the user.
Trivia: CIS Guidelines (security tasks applied to a server to pass an enhanced security audit to be compliant with a standard, in a soundbite) has an item requiring /var/tmp to be a bind mount to /tmp (as well as setting specific security options on /tmp). A server attempting to pass CIS audits (very common in my work-related experience w/Enterprises) may well not have a unique /var/tmp.
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#109Earlier quoted context omitted.
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
So maybe another filesystem with heavy checksums could be used? Btrfs or dm-crypt with integrity over ext4?
swapfile on linux must be directly mapped, bypassing any filesystem level checksums (see https://btrfs.readthedocs.io/en/latest/Swapfile.html)
Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
#110Earlier quoted context omitted.
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…
Yeah. I always disable overcommit (notwithstanding that Linux cannot provide perfectly accurate strict memory accounting), and I'd prefer not to use swap, but Linux VM maintainers have consistently stated that they've designed and tuned the VM subsystem with swap in mind. Is swap necessary in the abstract? No. Is swap necessary on Linux? No. But don't be surprised if Linux doesn't do what you'd expect in the absence…
> […] but Linux VM maintainers have consistently stated that they've designed and tuned the VM subsystem with swap in mind.
There is a citation for this that can be shown to skeptics?