Re: Moving /tmp to tmpfs makes it useless
Joey Hess <joeyh@debian.org> writes:
> Henrique de Moraes Holschuh wrote:
>> In fact it is the other way. We have /var/tmp for the large file since
>> about forever, and important platforms that have /tmp in memory since
>> the early 2000's (Solaris)....
>> And that STILL wasn't enough for people to not screw it up and dump
>> large files in /tmp.
> No, that is not the difference between /var/tmp and /tmp. Users of /tmp
> are not "screwing up", they are storing files that are intended only to
> persist while the computer is up, to the correct place.
> If programs that write large files to /tmp are changed to usr /var/tmp,
> then over time a system will accumulate orphaned large tmp files in
> /var/tmp. Nothing will come along and clean them up.
I started as one of the people in the "Solaris has been doing this for
years, what's the problem?" camp, but I find the argument presented by
Joey and others to be persuasive. If there are a wide variety of programs
that expect to be able to write files of arbitrary size to /tmp (and I
think it's fairly clear from the bug reports that there are, including
video streaming, sort, temporary unpacks of archives by file managers, and
even Debian's own tools like debdelta), tmpfs is (in most installations)
going to be much smaller than the typical available space on a physical
disk.
The root problem here is that we have multiple parameters that we want to
set on temporary storage:
1. Space for dumping arbitrary files without assuming anything about the
structure of the user's home directory.
2. Fast space for small temporary files that will be removed when the
system is rebooted.
3. Space for large temporary files that will be removed when the system is
rebooted.
Both /tmp and /var/tmp satisfy 1, but /var/tmp does not satisfy either 2
or 3. Previously, /tmp satisfied 3 but not 2. Now that it's switched to
tmpfs, it satisfies 2 but not 3.
In an ideal world, in which we could throw out all of UNIX history and
make up our own rules, 1 (alone) would be /var/tmp, 2 would be some new
path (/run/tmp or something), and 3 would be /tmp. But we don't live in
the world where it's likely we can convince everything to move to some new
/run/tmp location or the like.
Given that, we're not going to be able to satisfy 2 and 3 at the same
time. The advantage of 2 over 3 is speed while the advantage of 3 over 2
is functionality, and as a general rule of thumb functionality should be
preferred over speed. The argument before was basically that the
functionality improvement of 3 was a corner case, but I'm not sure from
this thread that we can support that conclusion.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: