Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!lll-lcc!lll-crg!seismo!mcvax!boring!jack
From: jack@boring.uucp (Jack Jansen)
Newsgroups: net.unix-wizards
Subject: Re: Ram disk with real disk "overflow"
Message-ID: <6888@boring.UUCP>
Date: Thu, 24-Apr-86 18:20:47 EDT
Article-I.D.: boring.6888
Posted: Thu Apr 24 18:20:47 1986
Date-Received: Fri, 2-May-86 23:21:16 EDT
References: <2213@brl-smoke.ARPA> <108@spock.fluke.UUCP> <6882@boring.UUCP> <347@oce-rd3.UUCP>
Reply-To: jack@mcvax.UUCP (Jack Jansen)
Organization: AMOEBA project, CWI, Amsterdam
Lines: 22
Keywords: RAM disc, disc caching
Apparently-To: rnews@mcvax

In article <347@oce-rd3.UUCP> grol@oce-rd3.UUCP (Geert Rolf) writes:
>In article <6882@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes:
>>Something I've been thinking of (but never came around to doing) is to
>>make a device of wich the first bit (say, .5Mb) is RAM disk, and the
>>rest is real disk.
>
>What do you want, Jack?? Another name/implementation for the disc-cache?
>
The point is, writing data to a real disk will eventually result
in a write operation. Even if your buffer cache is big, update
will force everything out to disk every minute or so.
If you can prevent this, that's nice. This is especially true for
files in /tmp. On your average file system, there are about three
times as many reads as writes. On /tmp, however, there are 1.2 reads
for every write.
Another way of achieving more-or-less the same result is giving the
buffer cache some knowledge about files (so it doesn't write blocks
belonging to files that are gone already). Finding 42 good reasons for
not doing this is left to the reader.
-- 
	Jack Jansen, jack@mcvax.UUCP
	The shell is my oyster.