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

1–10 of 137 posts

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

#2
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).

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

#4

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?

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.

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

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

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

#6

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?

Computers like a Raspberry Pi, where the OS is on a sdcard, will hugely benefit.

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

#7

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.

Dm-cache! https://www.kernel.org/doc/Documentation/device-mapper/cache...

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

#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 then it's really slow to read back.

This change is a mistake.

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

#9

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?

Computers like a Raspberry Pi, where the OS is on a sdcard, will hugely benefit.

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

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

#10
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.)

Post reply on HN