8 ms·

"The temporary-files directory /tmp is now stored in a tmpfs" - https://www.debian.org/releases/trixie/release-notes/issues.en.html#the-temporary-files-director

"The temporary-files directory /tmp is now stored in a tmpfs" - https://www.debian.org/releases/trixie/release-notes/issues.en.html#the-temporary-files-directory-tmp-is-now-stored-in-a-tmpfs https://www.debian.org/releases/trixie/release-notes/issues.... I am not a fan of that as a default. I'd rather default to cheaper disk space than more limited and expensive memory.

api 1y ago
Wait... that means a misbehaving program can cause out of memory errors easily by filling up /tmp? That's a very bad default.
- paulv 1y ago
  The default configuration for tmpfs is to "only" use 50% of physical ram, which still isn't great, but it's something.
  - foresto 1y ago
    To be clear, that 50% (or whatever you configure) is a limit, not a constant.
- CamouflagedKiwi 1y ago
  A misbehaving program can cause out of memory errors already by filling up memory. It wouldn't persist past that program's death but the effect is pretty catastrophic on other programs regardless.
  - o11c 1y ago
    That actually is a pretty big difference. Assuming you're sane and have swap disabled (since there is no way to have a stable system with swap enabled), a program that tries to allocate all memory will quickly get OOM killed and the system will recover quickly. If /tmp/ fills up your RAM, the system will not recover automatically, and might not even be recoverable by hand without rebooting. That said, systemd-managed daemons using a private /tmp/ in RAM will correctly clear it when killed.
    - mxey 1y ago
      https://chrisdown.name/2018/01/02/in-defence-of-swap.html https://chrisdown.name/2018/01/02/in-defence-of-swap.html
      - o11c 1y ago
        An ivory tower answer. All those arguments would be useful if we somehow could avoid the fact that the system will use it as "emergency memory" and become unresponsive. The kernel's OOM killer is broken for this, and userland OOM daemons are unreliable. `vm.swappiness` is completely useless in the worst case, which is the only case that matters. With swap off, all the kernel needs to do is reserve a certain threshold for disk cache to avoid the thrashing problem. I don't know what the kernel actually does here (or what its tunables are), because systems with swap off have never caused problems for me the way systems with swap on inevitably do. The OOM killer works fine with swap off, because a system must always be resilient to unexpected process failure. And worst of all - the kernel requires swap (and its bugs) to be enabled for hibernation to work. It really wouldn't be hard to design a working swap system (just calculate how much to keep of different purposes of swap, and launch the OOM killer earlier), but apparently nobody in kernel-land understands the real-world problems enough to bother.
        em-bee 1y ago
        the kernel requires swap (and its bugs) to be enabled for hibernation to work this one gets me irritated every time i think about it. i don't want to use swap, but i do want hibernation. why is there no way to disable swap without that? hmm, i suppose one could write a script that enables an inactive swap partition just before shutdown, and disables it again after boot.
        sigio 1y ago
        I never want to use hibernation, since then I have to re-enter my disk encryption passphrase at resume time, have to wait longer for both suspend and resume because it needs to sync upto 48GB to/from disk (and I don't want to waste 48GB of diskspace for swapspace/hibernation). Suspend to ram is fine, I can keep the system suspended for a couple of days without issues, but it only needs to survive a long weekend at most. Resume from RAM is about instant, and then just needs a screensaver unlock to get back to work.
_mlbt 1y ago
> You can return to /tmp being a regular directory by running systemctl mask tmp.mount as root and rebooting. >The new filesystem defaults can also be overridden in /etc/fstab, so systems that already define a separate /tmp partition will be unaffected. Seems like an easy change to revert from the release notes. As far as the reasoning behind it, it is a performance optimization since most temporary files are small and short lived. That makes them an ideal candidate for being stored in memory and then paged out to disk when they are no longer being actively utilized to free up memory for other purposes.
- hsbauauvhabzb 1y ago
  That seems like a bug with those applications which make use of the filesystem instead of performing in-memory operations or using named pipes.
  - esseph 1y ago
    "bug", more of a chosen design considering hardware constraints when things were designed.
    - hsbauauvhabzb 1y ago
      So send a PR or have a distro level patch if that’s the issue.
  - deleted 1y ago
    [deleted]
chromakode 1y ago
For users with SSDs, saving the write wear seems like a desirable default.
- Aachen 1y ago
  I have yet to hear of someone wearing out an SSD on a desktop/laptop system (not server, I'm sure there's heavy applications that can run 24/7 and legitimately get the job done), even considering bugs like the Spotify desktop client writing loads of data uselessly some years ago Making such claims on HN attracts edge cases like nobody's business but let's see
  - progmetaldev 1y ago
    I think you're 100% correct in that this isn't a normal event to occur. I believe it's probably one of those things where someone felt that setting it to memory is just more efficient in the general case, and they happened to be skilled in that part of development, and felt it added value. Maybe the developer runs a standard desktop version, but also uses it personally as a server for some kind of personal itch or software, on actual desktop hardware? Maybe I'm overthinking it, or the developer that wrote this code has the ability to fix more important issues, but went with this instead. I've tackled optimization before where it wasn't needed at the time, but it happened to be something I was looking into, and I felt my time investment could pay off in cases where resources were being pushed to their limits. I work with a lot of small to mid-sized businesses that can actually gain from seemingly small improvements like this.
pluto_modadic 1y ago
finally they're using a tmpfs. thank goodness <3
archargelod 1y ago
I'm using OpenSUSE Tumbleweed that has this option enabled by default. Until about a year ago, whenever I would try to download moderately large files (>4GB) my whole system would grind to a halt and stop responding. It took me MONTHS to figure out what's the problem. Turns out that a lot of applications use /tmp for storing files while they're downloading. And a lot of these applications don't cleanup on fail, some don't even move files after success, but extract and copy extracted files to destination, leaving even more stuff in temp. Yeah, this is not a problem if you have 4X more ram than the size of files you download. Surely, this is a case for most people. Right?
- hiq 1y ago
  How did you figure that this was the problem? If it's easily reproducible, I guess checking `top` while downloading a large file might have given a clue, since you could have seen that you're running out of memory?
  - archargelod 1y ago
    I was trying to solve another problem related to mounting, ran `df -h` a couple times and noticed that: 1) tmpfs is mounted to /tmp 2) available size on /tmp is very low 3) my free ram indicator in status bar is red And then I tried downloading some files while looking at htop. It was immeduately obvious that it was the problem causing the hangs.

api 1y ago

Wait... that means a misbehaving program can cause out of memory errors easily by filling up /tmp? That's a very bad default.

paulv 1y ago
The default configuration for tmpfs is to "only" use 50% of physical ram, which still isn't great, but it's something.
- foresto 1y ago
  To be clear, that 50% (or whatever you configure) is a limit, not a constant.
CamouflagedKiwi 1y ago
A misbehaving program can cause out of memory errors already by filling up memory. It wouldn't persist past that program's death but the effect is pretty catastrophic on other programs regardless.
- o11c 1y ago
  That actually is a pretty big difference. Assuming you're sane and have swap disabled (since there is no way to have a stable system with swap enabled), a program that tries to allocate all memory will quickly get OOM killed and the system will recover quickly. If /tmp/ fills up your RAM, the system will not recover automatically, and might not even be recoverable by hand without rebooting. That said, systemd-managed daemons using a private /tmp/ in RAM will correctly clear it when killed.
  - mxey 1y ago
    https://chrisdown.name/2018/01/02/in-defence-of-swap.html https://chrisdown.name/2018/01/02/in-defence-of-swap.html
    - o11c 1y ago
      An ivory tower answer. All those arguments would be useful if we somehow could avoid the fact that the system will use it as "emergency memory" and become unresponsive. The kernel's OOM killer is broken for this, and userland OOM daemons are unreliable. `vm.swappiness` is completely useless in the worst case, which is the only case that matters. With swap off, all the kernel needs to do is reserve a certain threshold for disk cache to avoid the thrashing problem. I don't know what the kernel actually does here (or what its tunables are), because systems with swap off have never caused problems for me the way systems with swap on inevitably do. The OOM killer works fine with swap off, because a system must always be resilient to unexpected process failure. And worst of all - the kernel requires swap (and its bugs) to be enabled for hibernation to work. It really wouldn't be hard to design a working swap system (just calculate how much to keep of different purposes of swap, and launch the OOM killer earlier), but apparently nobody in kernel-land understands the real-world problems enough to bother.
      - em-bee 1y ago
        the kernel requires swap (and its bugs) to be enabled for hibernation to work this one gets me irritated every time i think about it. i don't want to use swap, but i do want hibernation. why is there no way to disable swap without that? hmm, i suppose one could write a script that enables an inactive swap partition just before shutdown, and disables it again after boot.
        sigio 1y ago
        I never want to use hibernation, since then I have to re-enter my disk encryption passphrase at resume time, have to wait longer for both suspend and resume because it needs to sync upto 48GB to/from disk (and I don't want to waste 48GB of diskspace for swapspace/hibernation). Suspend to ram is fine, I can keep the system suspended for a couple of days without issues, but it only needs to survive a long weekend at most. Resume from RAM is about instant, and then just needs a screensaver unlock to get back to work.

_mlbt 1y ago

> You can return to /tmp being a regular directory by running systemctl mask tmp.mount as root and rebooting. >The new filesystem defaults can also be overridden in /etc/fstab, so systems that already define a separate /tmp partition will be unaffected. Seems like an easy change to revert from the release notes. As far as the reasoning behind it, it is a performance optimization since most temporary files are small and short lived. That makes them an ideal candidate for being stored in memory and then paged out to disk when they are no longer being actively utilized to free up memory for other purposes.

hsbauauvhabzb 1y ago
That seems like a bug with those applications which make use of the filesystem instead of performing in-memory operations or using named pipes.
- esseph 1y ago
  "bug", more of a chosen design considering hardware constraints when things were designed.
  - hsbauauvhabzb 1y ago
    So send a PR or have a distro level patch if that’s the issue.
- deleted 1y ago
  [deleted]

chromakode 1y ago

For users with SSDs, saving the write wear seems like a desirable default.

Aachen 1y ago
I have yet to hear of someone wearing out an SSD on a desktop/laptop system (not server, I'm sure there's heavy applications that can run 24/7 and legitimately get the job done), even considering bugs like the Spotify desktop client writing loads of data uselessly some years ago Making such claims on HN attracts edge cases like nobody's business but let's see
- progmetaldev 1y ago
  I think you're 100% correct in that this isn't a normal event to occur. I believe it's probably one of those things where someone felt that setting it to memory is just more efficient in the general case, and they happened to be skilled in that part of development, and felt it added value. Maybe the developer runs a standard desktop version, but also uses it personally as a server for some kind of personal itch or software, on actual desktop hardware? Maybe I'm overthinking it, or the developer that wrote this code has the ability to fix more important issues, but went with this instead. I've tackled optimization before where it wasn't needed at the time, but it happened to be something I was looking into, and I felt my time investment could pay off in cases where resources were being pushed to their limits. I work with a lot of small to mid-sized businesses that can actually gain from seemingly small improvements like this.

pluto_modadic 1y ago

finally they're using a tmpfs. thank goodness <3

archargelod 1y ago

I'm using OpenSUSE Tumbleweed that has this option enabled by default. Until about a year ago, whenever I would try to download moderately large files (>4GB) my whole system would grind to a halt and stop responding. It took me MONTHS to figure out what's the problem. Turns out that a lot of applications use /tmp for storing files while they're downloading. And a lot of these applications don't cleanup on fail, some don't even move files after success, but extract and copy extracted files to destination, leaving even more stuff in temp. Yeah, this is not a problem if you have 4X more ram than the size of files you download. Surely, this is a case for most people. Right?

hiq 1y ago
How did you figure that this was the problem? If it's easily reproducible, I guess checking `top` while downloading a large file might have given a clue, since you could have seen that you're running out of memory?
- archargelod 1y ago
  I was trying to solve another problem related to mounting, ran `df -h` a couple times and noticed that: 1) tmpfs is mounted to /tmp 2) available size on /tmp is very low 3) my free ram indicator in status bar is red And then I tried downloading some files while looking at htop. It was immeduately obvious that it was the problem causing the hangs.