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

131–137 of 137 posts

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

#131
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…

This doesn't really make sense. If /tmp was an on-disk directory the same memory pressure that caused swapping would just evict the file from the page cache instead, again leading to a cache miss and a dramatically slower read.

Reading it back from a filesystem is much much faster than reading it back from swap.

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

#132
post #13
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....

It's not about insufficient ram, it's about reserving ram for much more important things: cache.

This changes puts the least important data in ram - temp files - while evicting much more important cache data.

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

#133
post #130

Earlier quoted context omitted.

Neither i nor parent said that. Confusion?

You wrote your comment like it was a rebuttal of the person above you, but the text supports what they said: A filesystem is faster than swap for this. What was your intent?

[deleted]

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

#134
post #46

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…

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

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

#135

Earlier quoted context omitted.

The swap partition does not have a filesystem, it is a linear list of blocks.

Neither i nor parent said that. Confusion?

ext4 is irrelevant to what happens when a file is backed by swap; even with swapfiles, the mm subsystem more or less goes behind the back of the filesystem to access the disk corresponding to the swapfile.

The overhead of making (size-of-read / 4kb) requests (potentially stalling the reading process for every page) is relevant even on an ssd; there are costs to random access beyond moving a disk head and waiting for a platter to spin into position, and those costs are still relevant with solid-state storage.

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

#136
post #80

Earlier quoted context omitted.

I'm assuming that you monitor the service closely for OOM then adjust with demand ?

yeah 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)

Ive spent the last day thinking about that, I really can't see any big negative side effects, the only issue that I'd have is being notified of OOM conditions, and that would just be a syslog regex match. Great plan.

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

#137
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?

If you have checksum errors reading data from disk, you have much worse issues than ram corruption. Any program you launch will probably be corrupted.

Although if you do swap on a server (and you should), the swap needs to be on a raid, otherwise your server will crash on a disk error.

Swap on a server is not meant for handling low memory issues, instead there's tons of data on a server that's almost never used, so instead swap that out and make more room for cache.

Post reply on HN