Question on strategy() routines for - (nf)

[rpw3 at fortune.UUCP]

#R:hou2d:-22200:fortune:11600076:000:1579
fortune!rpw3    Mar 24 20:43:00 1984

Jim McGinnis says "just make the buffers bigger", rather than having
Tom Ballister's "RAM disk" device.

Well, there's a problem with that. As long as exec'ing a program flushes
the cache (indirectly, by loading it), with any kind of reasonable interactive
user load the cache never has any useful directory, i-node, or random-access
file data left in it.  All it has is copies of monsters like "vi" (which I
use, don't get me wrong). Ironically, the large programs will flush their OWN
directory entries, used earlier in the reading, and so get flushed (partially)
in turn when somebody runs the program again (it gets incestuous in there!).

In our most recent O/S release, we managed to get a quite significant
improvement in multi-user performance by throwing away any blocks that
had been involved in read-ahead once they were used. Practically, that
means that exec's never consume more than two buffer blocks, and one can
exec lots of large programs all day and never disturb the various pieces of
useful random-access data. (Much of our software is large, due to a heavy
"menu" orientation.)

I have no hard data to prove it in the environment being discussed (Ingres),
but I suspect that a "RAM disk" plus our "flush read-ahead" strategy would
give better performance than just an equivalent number of additional buffers,
especially since Ballister mentioned the file segments were several hundred K.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065