Xref: utzoo comp.unix.admin:114 comp.unix.internals:250 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!ark1!oasys!mimsy!chris From: chris@mimsy.umd.edu (Chris Torek) Newsgroups: comp.unix.admin,comp.unix.internals Subject: Re: Same device, two mount points? Or, overutilizing my RAM disk... Message-ID: <26525@mimsy.umd.edu> Date: 13 Sep 90 09:04:37 GMT References: <900908.7074@franklin.com> <1990Sep12.084002.5575@hq.demos.su> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 33 In article <1990Sep12.084002.5575@hq.demos.su> dvv@hq.demos.su (Dmitry V. Volodin) writes: >You'd better increase the size of your cache pool. The effect is much >better. Well, yes and no: one of the real benefits of a RAM /tmp is that file creation and deletion are synchronous operations, and they go a lot faster when waiting for RAM rather than a disk. :-) This is why 4.3BSD-reno has the virtual memory file system type. VMFSes use RAM when it is available, or backing store (swap space) otherwise. Note that you must change vi to store its temporary files on a real disk so that it can recover edit sessions after power failures, etc. (I realize you Californians do not have daily power failures every summer like those of us on the east coast.... Thunderstorms, is why.) >Folks, does anyone want to discuss the pros and cons of placing the >swap/pageing area onto the ram disk? :) Although this was not intended seriously, there are some Unix kernels out there where this would help. Ten years ago some of the popular machines (VAX-11/780...) were better at DMA I/O than cpu-mediated memory-to-memory copies, and therefore a number of operations were done using the paging area as a sort of memory-to-memory DMA device. This is supposed to be fixed Real Soon Now. >internet: Do svedanya, <- will this get me into the NSA archives? :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris