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]
Hi,
On 5/6/24 17:40, Michael Biebl wrote:
If we go with a/, then I think d-i should be updated to no longer create
/tmp as a separate partition.
I think if the admin explicitly configures tmpfs as a separate file
system, then that should be honored -- if there is memory pressure,
tmpfs+swap is pretty much the worst file system there is.
For example, I have a VM with 32 threads but only 16 GiB of memory
allocated to it, which is normally sufficient for compiling large
projects, but occasionally starts thrashing really hard, and /tmp on
ext4 with very relaxed ordering rules is a good way to make it behave.
(What we're really want is a file system that behaves like
FILE_ATTRIBUTE_TEMPORARY on Windows, where backing store is allocated,
and pages are evicted first on memory pressure, but are not flushed
automatically)
Regarding b/:
The current setup as used in Debian is to only clean /tmp on boot (which
is pointless with /tmp-on-tmpfs) and never clean up /var/tmp
There is also the tmpreaper package, which does periodic cleanup based
on atime. I'd expect that to be installed on a lot of long-running
machines, it is certainly installed on mine.
Also if /var/tmp is no longer cleaned on boot, that is a bug.
I'm not sure if we have software on long running servers which place
files in /tmp and /var/tmp and expect files to not be deleted during
runtime, even if not accessed for a long time. This is certainly an
issue to be aware of and keep an eye on.
IIRC it was an explicit decision not to install tmpreaper by default and
leave cleanup policies to the local admin, for precisely this reason.
It makes sense to revisit this decision 20 years later, but a lot of the
original rationale remains valid: it affects only a handful of machines
(because everyone else reboots often anyway), and we kind of expect
those machines to be operated by skilled people.
Simon
Reply to: