Path: utzoo!attcan!uunet!comp.vuw.ac.nz!virtue!canterbury.ac.nz!cosc038 From: cosc038@canterbury.ac.nz Newsgroups: comp.unix.internals Subject: Re: RAM disk. Message-ID: <1990Oct10.152556.9367@canterbury.ac.nz> Date: 10 Oct 90 13:08:56 GMT References: <18560@rpp386.cactus.org> <143359@sun.Eng.Sun.COM> <18574@rpp386.cactus.org> <1850@necisa.ho.necisa.oz> Organization: University of Canterbury Lines: 43 There's been some pretty heated discussion on this topic lately [most of it deleted] Boyd Roberts, for instance, writes: In article <1850@necisa.ho.necisa.oz>, boyd@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@cosc.canterbury.ac.nz NZ Telecom: Office: +64 3 667 001 x6350 NZ Post: Dept of Computer Science University of Canterbury, Christchurch, New Zealand