Question on strategy() routines

[Jim McGinness]

You're off the mark, Rob.  The fill-on-demand-from-inode programs are
not read in through the buffer cache.  If they were, then Ballister
would not have had the problem he reported.

My comment about increasing the size of the system buffer cache was intended
to head off efforts to implement the in-memory device in situations where
it isn't justified.  I would prefer that attention be given to how improve
the automatic management of the storage hierarchy.

Until that golden day, it's quite possible for someone to know better
than the default routines what the system's needs are.  In some of
those cases, it can make sense to lock things into physical memory.
Ballister had some specific performance enhancements he was trying to
achieve and might be able eventually to statically tune his system for
the proper balance between memory devoted to system memory and memory
devoted to the in-memory device.

One thing in particular that is better handled through the buffer cache than
through an in-memory device is /tmp.  An anecdote is appropriate here:

	Several months ago, we brought decvax's system pack up on a 750
	with 8Mb.  In single-user-mode, we started to rebuild the
	kernel to pick up some of the new devices this 750 had.
	Partway through, there was a power glitch.  When the system
	came back up, we discovered an unholy mess in the file system.

	The "mess" was scads of zero-length .o files.  Decvax's kernel
	had been "tuned" to use 400 system buffers, so we had
	essentially been compiling to memory.  With `update' not
	running, only the inodes and directory blocks were actually
	being written out to disk.

I guess the moral of this story is that putting /tmp into volatile
storage may cause you to lose the value of `expreserve'.

						Jim McGinness
	decvax!jmcg				Digital Equipment Corp.
	(603)844-5703				MKO2-1/H10
						Merrimack, NH, 03054