Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!Teknowledge.COM!unix!garth!fouts@bozeman.ingr.com (Martin Fouts) From: fouts@bozeman.ingr.com (Martin Fouts) Newsgroups: comp.arch Subject: Re: Real disk FASTER than Ram disk Message-ID: <431@garth.UUCP> Date: 7 Jun 90 18:46:14 GMT References: <641@sibyl.eleceng.ua.OZ> <136299@sun.Eng.Sun.COM> <1990May27.210935.8564@murdoch.acc.Virginia.EDU> <3402@auspex.auspex.com> <60196@lll-winken.LLNL.GOV> <5490@titcce.cc.titech.ac.jp> Sender: fouts@garth.UUCP Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 34 In-reply-to: mohta@necom830.cc.titech.ac.jp's message of 31 May 90 13:23:44 GMT In article <5490@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > It's trivial to avoid the extra copy. Maybe. But, writing a memory disk device driver is already non-trivial. Moreover, a memory disk has several limitations including its maximum size. > A better solution (as has been pointed out) is to allow for memory >resident file systems that are only written out to backing disk when >space is needed. That is what I have described in a paper titled: A fast /tmp file system by delay mount option Excuse me for disagreeing, but replacing /tmp with a file system that gets paged isn't a good solution. What you are doing here is working around the lack of advance in the underlying software. The compiler is still writing to /tmp because it isn't managing its own address space effectively in a virtual memory environment. Direct mapping files into the compiler address space and paging from that is much more effective than using a second order paging for a "file system" ala /tmp. -- Martin Fouts UUCP: ...!pyramid!garth!fouts ARPA: apd!fouts@ingr.com PHONE: (415) 852-2310 FAX: (415) 856-9224 MAIL: 2400 Geng Road, Palo Alto, CA, 94303 If you can find an opinion in my posting, please let me know. I don't have opinions, only misconceptions.