The /tmp/ as tmpfs discussion is funny to me because while we've been kicking around the idea of whether or not to clean /tmp/, having /tmp/ as a tmpfs makes that whole argument moot. It all goes away at boot time! Problem solved! :D
Honestly, I see this one as a much easier topic, assuming that no one is talking about changing existing systems. (I haven't seen anyone say that.) So for new systems, /tmp/ as a tmpfs strikes me as a legitimate option, and the partition layout is something that any good admin pays close attention to on any new system, particularly a new distribution or even distro version. (That is, even going from 12.1 to 12.2, I'm going to be on the lookout for changes in the installer.) Whether you want /tmp as a tmpfs is a decision that's going to be made at the same time as whether or not /home should be on a separate partition. The admin is going to do whatever makes the most sense for this system. To me, it's all about the display. I want to see what partition will be mounted as root, what partition will be mounted as /home, which will be swap (if any), and so on. But I don't need to see /proc and /sys. Those aren't optional. So if /tmp is not part of the root partition, it doesn't matter if it's a separate partition or a tmpfs. It should just appear in the screen that displays the filesystem layout, and then the admin can decide whether or not that's a good idea. I have no opinion on whether or not it should be the default. If /tmp/ as tmpfs becomes the default, I would probably only override that on certain low-memory systems that I run and just leave it on most others. I've seen it done before and it seemed to work fine in some cases and not in others. As long as it's somewhere that I can SEE it in the installer, I'd be happy. That's definitely a thing the admin can change later on with few consequences. Sent from my mobile device. ________________________________ From: Hakan Bayındır <ha...@bayindir.org> Sent: Tuesday, May 7, 2024 05:45 To: 966...@bugs.debian.org; debian-devel@lists.debian.org Cc: Carsten Leonhardt; Luca Boccassi; Peter Pentchev Subject: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default] Similarly, I’m following the thread for a couple of days now, and wondering about its implications. When I consider server scenarios, pushing /tmp to RAM looks highly undesirable from my perspective. All the servers I manage use their whole RAMs and using the unused space as a disk cache is far more desirable than a /tmp mount. When servers are virtualized, RAM is at premium, and a disk cache is way more usable rather than /tmp in the RAM. The other scenario I think is HPC, where applications use all the RAM available, squeezing the hardware dry. Again, /tmp in the RAM is very undesirable, because /tmp/$USER is also heavily used and an OOM situation creates a lose-lose situation where you either delete runtime files, or lose the executing job, which results in job failure in any case. On the other hand, I personally use my desktop computer as a development workstation and use tons of RAM either with software or with VMs. Again a /tmp in RAM is an inferior scenario to my current setup. The only useful state where /tmp is in RAM is single board computers where temp is both lightly utilized and maximizing SD/eMMC life is important. These systems even mount /var/log to a tmpfs and sync on boot/reboot/shutdown, reducing flash wear. Deleting /var/tmp has the same problems since long running tasks on the servers might need a file once in a month, but it can be crucial for functions of the software. I can’t see any scenario where these two are useful in typical or niche installations of Debian. FWIW, RedHat family doesn’t mount /tmp as a tmpfs on its default installation. Cheers, H.
