Debian's /tmpest in a teapot

Original Article ↗ Hacker News Discussion ↗

Debian’s plan to mount `/tmp` as a RAM-backed `tmpfs` and to auto-clean files in `/tmp` and `/var/tmp` is prompting debate over performance, data loss risk, and adherence to long‑standing filesystem standards. Supporters argue that using memory for truly temporary data is faster, reduces SSD wear, and can be tuned or disabled by admins, while critics warn that changing long-persistent semantics will break workflows that store large or long‑running temporary data, particularly in scientific and multi-user environments. The exchange broadens into concerns about backwards compatibility, the role of systemd in defining system behavior, and the lack of consistent conventions for where applications and users should put ephemeral versus cache or persistent data.

Debian’s /tmp-on-tmpfs and cleanup policy

  • Debian is switching the default /tmp to tmpfs and enabling timed cleanup of /tmp and /var/tmp via systemd-tmpfiles.
  • Some see this as overdue alignment with other distros and a net win: fewer disk writes, automatic cleanup, consistency across installs.
  • Others stress it breaks long-standing expectations: /tmp as large, disk-backed scratch space; /var/tmp as “temporary but persistent across reboots,” per FHS and historical Unix practice.

Performance, RAM, SSD wear

  • Proponents: RAM is fast, SSD wear is finite, and temp data is ideal to keep off SSDs. For many desktops with ample RAM, /tmp in RAM is beneficial.
  • Critics: RAM is “precious,” especially on smaller/cheaper laptops and servers. Large temps in tmpfs force swapping and can destabilize systems; for big builds or ISOs, disk is faster than swap-thrashing tmpfs.
  • Some argue modern filesystems and cache already keep hot /tmp data in RAM, so explicit tmpfs brings little speed benefit.

Usage patterns and breakage concerns

  • Many users and tools already rely on /var/tmp or even /tmp as semi-persistent storage (long simulations, browser profiles, caches, tmux/ssh-agent sockets).
  • Automatically reaping files while the system is running (based on last access time) is seen as risky; fear of partially deleted app state and subtle failures.
  • Others counter that using temp dirs for important or long-lived data was always fragile; affected users should move to proper cache/data paths or site-specific dirs.

XDG directories and ~/.cache on tmpfs

  • XDG base dir spec is widely discussed: half-adoption leads to cluttered $HOME and inconsistent behavior.
  • Some put ~/.cache on tmpfs to save SSD wear; others say this breaks workflows that rely on persistent caches or large ML models stored there.

Swap, memory policy, and tuning

  • Extensive side discussion on swap size, zswap/zram, swappiness, and early OOM killers.
  • Opinions split between preferring slowdown with swap vs. aggressive killing to avoid thrashing.

Backwards compatibility, configurability, and systemd’s role

  • Some argue changing long-standing semantics violates user expectations; defaults should favor compatibility, with new behavior opt-in.
  • Others emphasize Debian’s configurability: /etc/fstab, masking tmp.mount, and tmpfiles.d allow reverting behavior, and admins are expected to adapt.
  • There is unease about systemd owning more policy knobs (mounts, tmp handling), but also acknowledgment that its tmpfiles mechanism is powerful and central to this change.