7 ms·
A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it
- GCUMstlyHarmls 1y agoActually 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 1y agoIf 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?
- techjamie 1y agoTechnically 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.
- margalabargala 1y agoComputers like a Raspberry Pi, where the OS is on a sdcard, will hugely benefit.
- jauntywundrkind 1y agoYup. 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 https://raspberrypi.stackexchange.com/a/186/32611
- renewiltord 1y agoWhy 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.
- jauntywundrkind 1y agoDm-cache! https://www.kernel.org/doc/Documentation/device-mapper/cache.txt https://www.kernel.org/doc/Documentation/device-mapper/cache...
- jona-f 1y agoDo you mean that you can mark files for which still the underlying filesystem is used? As far as I remember there were experiments with that about 20 years ago, but it was decided that the added complexity wasn't worth it. The implementation that replaced all of that has been very stable (unlike the ones before) and i'm using it heavily, so i think they had a point. Some write-through behavior can be scripted on top of that. EDIT: So, wikipedia lists overlayfs and aufs as active projects and unionfs predates both. Maybe unionfs v2 is what replaced all that? Maybe I'm hallucinating...
- renewiltord 1y agoOverlayfs doesn't write through, and I believe unionfs and aufs no longer support write-through. What I want is pretty much like how a write-through cache would work. 1. Write to top-level FS? The write cascades down but reads are fast immediately 2. Data not available in top-level FS? The read goes down to the bottom level and then reads up to the top so future reads are fast.
- ars 1y agoFile 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 1y agoWhy 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 1y agoBecause swapping back in happens 4kb at a time
- cycomanic 1y agoWhy?
- worthless-trash 1y agoBecause of page size. Its treated like any other page.
- mnw21cam 1y agoIt'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.
- blueflow 1y agoValid argument with FAT on spinning rust, invalid with ext4 on ssd. ext4 is extent-based so the fragmentation overhead doesn't happen.
- ComputerGuru 1y agoI 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.)
- nrdvana 1y agoThe 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 1y agoWhich is a great reason to have a big swap file now.
- gnyman 1y agoNote 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. [1] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/4/html/introduction_to_system_administration/s2-memory-concepts-swapping https://docs.redhat.com/en/documentation/red_hat_enterprise_...
- baq 1y agoThis 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.
- worthless-trash 1y agoI'm assuming that you monitor the service closely for OOM then adjust with demand ?
- baq 1y agoyeah pretty much, also configuring memory limits everywhere where apps allow it. some software also handles malloc failures relatively gracefully, which helps a whole lot (thank you postgres devs)
- gigatexal 1y agoWhy 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.
- rwmj 1y agoIt's a dumb idea that came from the systemd people. They've never explained properly why it's a good idea, but it's the systemd default and for some reason distros defer to that.
- egorfine 1y agoNot at all. tmpfs precedes systemd for like a decade.
- rwmj 1y agoIt 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.
- Incipient 1y agoUsing 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 1y agoWho runs around with a 100gb+ /tmp partition? Our default server images come with a 4.4GB /tmp partition...
- wielebny 1y agoI run a script that rotates my /tmp/ each day, so I can access yesterday's tmp files at /tmp/20250828/ and so on. My /tmp is my default folder for downloads and temporary work. It will grow 100GB+ easily.
- cycomanic 1y agoSure, 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/ch03s18.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.htm... Now you can obviously use your Filesystem whichever way you like, but I would say Debian shouldn't have to take into consideration uses which are outside the general recommendations/specs.
- 1718627440 1y agoPrograms shouldn't assume that about /tmp, the user advising this is fine.
- pessimizer 1y ago
- computatrum 1y agoThe mentioned periodic clean up of tmp files is not enabled out-of-the-box in case of a upgrade from previous Debian versions, see https://www.debian.org/releases/trixie/release-notes/issues.en.html#the-directories-tmp-and-var-tmp-are-now-regularly-cleaned https://www.debian.org/releases/trixie/release-notes/issues.... .
- fh973 1y agoSwap 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 1y agoThat'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.
- yjftsjthsd-h 1y agoZFS /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 https://github.com/openzfs/zfs/issues/7734
- abrookewood 1y agoAh, thanks for pointing that out - wasn't aware.
- cromka 1y agoSo maybe another filesystem with heavy checksums could be used? Btrfs or dm-crypt with integrity over ext4?
- tatref 1y agoWhy not dm-integrity?
- yjftsjthsd-h 1y agohttps://wiki.archlinux.org/title/Dm-integrity https://wiki.archlinux.org/title/Dm-integrity > It uses journaling for guaranteeing write atomicity by default, which effectively halves the write speed. That seems like a poor fit for swap IMO. https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html https://www.kernel.org/doc/html/latest/admin-guide/device-ma... says, > There’s an alternate mode of operation where dm-integrity uses a bitmap instead of a journal. If a bit in the bitmap is 1, the corresponding region’s data and integrity tags are not synchronized - if the machine crashes, the unsynchronized regions will be recalculated. The bitmap mode is faster than the journal mode, because we don’t have to write the data twice, but it is also less reliable, because if data corruption happens when the machine crashes, it may not be detected. It's not clear to me if that would be okay for swap (as long as you don't hibernate, maybe) or if it's sufficiently protected from corruption.
- worthless-trash 1y agoI'm still a fan of poly instantiated /tmp and PrivateTmp (systemd). This may confuse/annoy admins who are not aware of namespaces, but I know that it definitely closes the attack vector of /tmp abuse by bad actors. https://www.redhat.com/en/blog/polyinstantiating-tmp-and-vartmp-directories https://www.redhat.com/en/blog/polyinstantiating-tmp-and-var...
- greatgib 1y agoI'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 to be the place where you could store cache or other things like that that will hold until next reboot. It looks so arbitrary and source of random unexpected bugs to have files being automatically deleted there after random time. I don't know where this feature comes from, but when stupid risky things like this are coming, I would easily bet that it is again a systemd "I know best what is good for you" broken feature shoved through our throats... And if coming from systemd, expect that one day it will accidentally delete important filed from you, something like following symlinks to your home dir or your nvme EFI partition...
- PhilipRoman 1y agoI agree about the auto cleanup, I discovered it a few days after using /tmp as a ramdisk for Yocto build. Lost a few patches but nothing significant.
- loa_in_ 1y agoI 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 - how often, what should stay, tie file lifetime to machine reboot? The answers to these questions vary more between applications than between filesystems, therefore it's more flexible to leave clean up to userspace. In the end my main concern turned out to be that I lost files that I didn't want to lose, either to reboot cleanup, on timer cleanup, etc. I opted to clean up my temp files manually as needed.
- cl3misch 1y agoA tmpfs itself is basically a ramdisk by definition. I assume you mean /tmp when you say tmpfs?
- rwmj 1y ago'systemctl mask tmp.mount' - the most important command to run in these situations. It's a really bad idea to put /tmp into memory. Filesystems already use memory when necessary and spill to the filesystem when memory is under pressure. If they don't do this correctly (which they do) then fix your filesystem! That will benefit everything.
- nolist_policy 1y agoYou'd think that, but in ext4 the first write to a new file will hit the disk (the code mentions it is a workaround for something). Btrfs does it correctly.
- rwmj 1y agoSounds like fixing that ext4 problem could make a lot of things go faster.
- euLh7SM5HDFY 1y ago[dead]
- deleted 1y ago[deleted]
- noobermin 1y agoAs someone who sort of needs to juice all my ram, this is annoying but at least it can be turned off.
- probably_wrong 1y agoThe 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.
- celeryd 1y agoWe 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.
- Paul_S 1y agoI read the article and I really don't understand. Linux already buffers files into RAM if there's any unused, why would you do this?
- blueflow 1y agoThe "so you wont need to read files from disk" argument is bullshit because tmpfs data can be evicted to swap. If memory pressure is high you will still be reading from disk. And high memory pressure is also what makes disk-backed /tmp slow. No improvement at all.
- apexalpha 1y agoI 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?
- rubatuga 1y agoSame budget
- 1vuio0pswjnm7 1y agoI havent used a non-tmpfs (disk-based) /tmp in over 15 years Didnt need it on NetBSD, memory could go to zero and system would (thrash but) not crash. When I switched to Linux the OOM issue was a shock at first but I learned to avoid it I use small form factor computers, with userland mounted in and running from memory, no swap; I only use longterm storage for non-temporary data https://www.kingston.com/unitedkingdom/en/blog/pc-performance/what-is-ram-disk https://www.kingston.com/unitedkingdom/en/blog/pc-performanc...
- tgtweak 1y agoThis is precisely what /dev/shm is for... And it can be used explicitly without any gotchas. If someone really wanted tmp to be in memory (to reduce SSD endurance writes or speed it up nominally) they can edit their mounts. This feels like a very unnecessary change and nothing in that article made a convincing argument for the contrary.