Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

lowendbox.com

Post reply on HN
Print view View original

41–50 of 137 posts

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#41

Post by cycomanic »

wielebny wrote: post #32
perlgeek wrote: post #22

Earlier quoted context omitted.

Who runs around with a 100gb+ /tmp partition? Our default server images come with a 4.4GB /tmp partition...

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

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

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#42

Post by yjftsjthsd-h »

abrookewood wrote: post #27
fh973 wrote: post #23

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?

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

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#43

Post by perlgeek »

wielebny wrote: post #32
perlgeek wrote: post #22

Earlier quoted context omitted.

Who runs around with a 100gb+ /tmp partition? Our default server images come with a 4.4GB /tmp partition...

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

Your use case sounds more like "scratch" folder, not really what /tmp is meant for.

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#44

Post by pixelesque »

imp0cat wrote: post #13
ars wrote: post #8

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

Most systems probably aren't having problems with insufficient RAM nowaday though, do they? And this will reduce wear on your SSD. Also, you can easily disable it: https://www.debian.org/releases/trixie/release-notes/issues....

On small VPS systems with 512 MB or 1 GB you're more likely to notice (if /tmp is actually used by what's running on the sytem).

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#45

Post by Balinares »

edoceo wrote: post #33
m463 wrote: post #30

Earlier quoted context omitted.

what swap partition? I meant this sort of jokingly. I think have a few linux systems that were never configured with swap partitions or swapfiles.

I'm with you. I don't swap. Processes die. OOM. Linux can recover and not lose data. Just unavailable for a moment.

Swapping still occurs regardless. If there is no swap space the kernel swaps out code pages instead. So, running programs. The code pages then need to be loaded again from disk when the corresponding process is next scheduled and needs them.

This is not very efficient and is why a bit of actual swap space is generally recommended.

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#46

Post by jona-f »

renewiltord wrote: post #5

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.

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

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#47

Post by KronisLV »

wielebny wrote: post #32
perlgeek wrote: post #22

Earlier quoted context omitted.

Who runs around with a 100gb+ /tmp partition? Our default server images come with a 4.4GB /tmp partition...

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

This reminded me of the spacebar heating xkcd: https://xkcd.com/1172/

(not making fun of the workflow or anything, it's just that changes like tmpfs breaking stuff very much holds true)

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#48

Post by nolist_policy »

Incipient wrote: post #17

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?!

Use `/var/tmp` of you want a disk backed tmp. Not sure why the article omits that.

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#49

Post by greatgib »

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

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#50

Post by rwmj »

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

Post reply on HN