Xref: utzoo comp.unix.internals:663 alt.religion.computers:1938
Path: utzoo!utgpu!freedom!elroy.jpl.nasa.gov!usc!cs.utexas.edu!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals,alt.religion.computers
Subject: Re: RAM disk.
Message-ID: <6372@titcce.cc.titech.ac.jp>
Date: 15 Oct 90 03:56:51 GMT
References: <18574@rpp386.cactus.org> <1850@necisa.ho.necisa.oz> <BZS.90Oct9144959@world.std.com> <1990Oct11.185949.29164@iconsys.uucp>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 32

In article <1990Oct11.185949.29164@iconsys.uucp>
	malc@iconsys.uucp (Malcolm Weir) writes:

>OK, Reach For Your Revolver... Make My Day! But you dudes who say "RAM disks?
>Unnecessary, 'cos we've got a Buffer Cache!!" are WRONG, INCORRECT, MISTAKEN,
>and basically WAY OUT OF LINE.

Not so much.

>Really? just how do you persuade *nix to cache "/lib/*", in prefence to 
>Joe Unimportant-User's huge statistical jobs that have been munging vast
>amounts of data for the past 12 days?

As /lib is almost readonly, I recommend you to tune BSD file system
parameters such as maxcontig with appropriate disk controllers.

Then, you can read entire /lib/libc.a with a single seek.

>How do you persuade it that the
>disk accesses caused by the backup of "/irrelevant" are less important than
>the accesses caused by the CEO's secretary's WP temp files?

CEO's secretary should have his own workstation, of course.

>(btw, I used to be anti-RAM-disk, 'till I tried a system with "/lib"
> on RAM. "/tmp" didn't make that much difference, but you should've
> seen "ld" fly... )

If you are using your own workstation with large memory and dynamic
buffer caching, you can observe the same thing.

						Masataka Ohta