RAM disk.

[cosc038 at canterbury.ac.nz]

There's been some pretty heated discussion on this topic lately

[most of it deleted]

Boyd Roberts, for instance, writes:

In article <1850 at necisa.ho.necisa.oz>, boyd at necisa.ho.necisa.oz (Boyd Roberts) writes:
> When I hear `ram disk' I reach for my revolver.  Now, repeat after me...
> 
>     What is the buffer cache? -- A ram disk.
> 
> Increase NBUF and throw tmpfs away.  Vote 1 comp.unix.gizzards.

(Larry McVoy is talking about SunOS 4.1, where there is no longer any
distinction between the buffer cache and the physical memory
available for virtual memory - but that's beside the point).

I tend to agree with most posters who have expressed sentiments similar to
Boyd's, if we are talking about a single machine with disc.  However
tmpfs could be a very big win where /tmp would otherwise be NFS-mounted.
This is because EVERY write to an NFS-mounted /tmp would have to be written 
synchronously to a remote disc, whereas every write to a tmpfs file system
would go no further than local RAM.

We have seen something similar here in the Department.  Ordinarily
the various processes involved in doing a cc(1) communicate using files
in /tmp.  There is a -pipe option which connects the cc(1) processes
directly using pipes, with no need for /tmp files.  The cc(1) man page
comments that the -pipe option is "Very CPU intensive".  We have found
though that when a server is heavily loaded compiles run MUCH more
quickly on clients if the -pipe option is used.  I would put this
down to the fact that when the -pipe option is used a lot less
synchronous NFS writes to /tmp are required.

So perhaps Larry McVoy and the other posters have been talking a little
at cross-purposes?
                  
-- 
Paul Ashton
Email(internet): paul at cosc.canterbury.ac.nz
NZ Telecom:     Office: +64 3 667 001 x6350
NZ Post:        Dept of Computer Science
                University of Canterbury, Christchurch, New Zealand