It occurred to me that Geert Hendrickx wrote in gmane.os.netbsd.general:
> On Wed, Aug 31, 2005 at 05:38:05PM +0000, Martijn van Buul wrote:
>> > /tmp	If you've got the RAM, some people like to make this a mfs
>> >         (memory filesystem) carved out of RAM.
>> 
>> And even if it's not a machine with a lot of RAM, making it a ramdisk is
>> still an interesting thing to do, as long as you make sure it's backed
>> with swapspace. So increase the swapspace with the amount of diskspace
>> you had in mind for /tmp. As long as we don't have tmpfs, a RAMdisk is a
>> lot faster than a softdep filesystem, even if this means the ramdisk
>> needs to be swapped out.
>
> Just a question: how does this work on machines without swap?  

There will be swap:

>> So increase the swapspace with the amount of diskspace
>> you had in mind for /tmp.

So if you want a 256 MB /tmp partition, raise swap by 256 MB and make that
256 MB ramdisk.

The amount of free (virtual) memory doesn't change that much. The amount of
memory available to the system doesn't really change either. When /tmp is
rather empty, as it is usually the case, a 256 MB ramdisk will eat only 
a marginal amount of memory. If it's in use, it will not take a considerably
higher amount of physical memory than it's "partition counterpart"; the latter
will be kept in filesystem cache as long as possible anyway. The reason that 
it is interesting for /tmp is that /tmp typically has a high amount of 
file creation and deletion - and usually rather small files at that. softdeps
isn't really efficient at that, as it tries really hard to keep the on-disk
filesystem image consistent. And while this is a virtue for all other 
filesystems, it's basicly a waste of effort on /tmp, as /tmp doesn't survive
a reboot anyway. 

So, what happens if the system is running out of free physical memory, and
there's a large unused file in the ramdisk? It'll be the first page to be 
swapped out, since it's unused. Note that if it were a "real" filesystem, it
would be cached out at this point, so there is nothing lost. 

Finally, by raising the amount of swapspace by the size of the ramdrive, you
will assert that your system will not run out of memory because of it. You
will not loose any diskspace because of this, since you can spare the /tmp
partition. The only catch is that, in a worst-case scenario, your ramdrive
might not be able to reach its full size, because the memory usage of the rest
of the system has grown beyond what you initially set as a limit - it is using
the swap you set aside for the ramdrive, meaning that you probably would've ran
into troubles on the "filesystem /tmp" machine earlier, due to memory shortage.

> TMPDIR?  What's that?  What programs use it?  

Gcc - one of the biggest benefitors from this scheme. Shellscripts that use
mktemp. perl5. And most other programs that use temporary files.

Most programmers will "just" use something in /tmp, but it's actually good
behaviour to use TMPDIR. And TMPDIR gets set to /usr/tmp by default, so that's
what gcc et al will use.

Martijn (Who thinks that swap shouldn't be turned off to begin with, unless
there's good reason to)