[UNIX traditionally has two places to put temporary files: /tmp and /usr/tmp. This article explains how that started. -JP]
As I understand it, the reason for the /tmp-/usr/tmp split is identical to the reason for the /bin-/usr/bin and /lib-/usr/lib splits and is a historical accident of hardware configuration at the Research system.
At one time (circa the time of the original UNIX paper in CACM), the Research machine was a PDP 11/45 with a fixed-head disk, some RK05s, and an RP03. The root went on the fixed-head disk, since the absence of seek times made it fast. But fixed-head disks (anybody remember them?) were tiny. Two megabytes [sic] was a big fixed-head disk. So you had to be fairly careful to avoid overflowing the root filesystem (which included /tmp-it wasn't a separate filesystem). /usr, on the other hand, was the main filesystem on the 40-MB RP03.
So you had a very sharp split of hardware: things directly under /, like /tmp, /bin, and /lib, were fast but had to be small; things under /usr could be big but accesses to them were slower. So you put the heavily used commands in /bin, the heavily used libraries in /lib, and [flourish of trumpets] the small temporary files in /tmp. All the other slush went under /usr, including a /usr/tmp directory for big temporaries. This is why a few programs likeput their temporaries in /usr/tmp: they expect them to be big. [Though most /usr filesystems are fast these days, a lot of systems still have much more room on /usr/tmp than /tmp. -JP ]
In practice, fixed-head disks are historical relics now, and much of the justification for the various /x-/usr/x splits has disappeared. There is one reason why you might retain a /tmp-/usr/tmp split, however. If your /tmp filesystem is kept in "RAM disk" or something similar for speed, you might want to keep your editor temp files somewhere else if your editor has. Crash recovery definitely works better when the files it is looking for are kept in nonvolatile memory!
- in net.unix on Usenet, 19 March 1984