Simon Richter <s...@debian.org> writes: > On 5/8/24 07:05, Russ Allbery wrote:
>> It sounds like that is what kicked off this discussion, but moving /tmp >> to tmpfs also usually makes programs that use /tmp run faster. I >> believe that was the original motivation for tmpfs back in the day. > IIRC it started out as an implementation of POSIX SHM, and was later > generalized. I believe you're correct for Linux specifically but not in general for UNIX. For example, I'm fairly sure this is not the case on Solaris, which was the first place I encountered tmpfs and where tmpfs /tmp was the default starting in Solaris 2.1 in 1992. tmpfs was present in SunOS in 1987, so I'm pretty sure it predates POSIX shared memory. Linux was very, very late to the tmpfs world. > When /var runs full, the problem is probably initrd building. I'm not quite sure what to make of this statement. On my systems, /var contains all sorts of rather large things, such as PostgreSQL databases, INN spool files, and mail spools. I have filled up /var on many systems over the years, and it's never been by building initrd images. > Taking a quick look around all my machines, the accumulated cruft in > /var/tmp is on the order of kilobytes -- mostly reportbug files, and a > few from audacity -- and these machines have not been reinstalled in the > last ten years. Yes, I don't think many programs use it. I think that's a good thing; the specific semantics of /var/tmp are only useful in fairly narrow situations, and overfilling it is fairly dangerous. Back in the day, /var/tmp was the thing that you used if /tmp was too small (because it was usually tmpfs). For example, using sort -T /var/tmp to sort large files is an old UNIX rune. And, of course, students would use it because they ran out of quota in their home directories and then get upset when their files got deleted automatically, back in the days of shared UNIX login clusters. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
