V7 buffer cache question.

[Rob Warnock]

+---------------
| I heard a rumour that someone in unix-land had hacked the
| buffer allocation routines so that reading a large program
| doesn't effectively flush your buffer cache...
+---------------

True. This policy is implemented in the Fortune Systems 32:16's version
of UNIX, called FOR:PRO, which has a (nearly) V7 filesystem (but with
1024 byte blocks).

+---------------
| ...in a normal V7 (the oldest block is allocated every time something
| is needed, so reading something big results in all your useful
| buffers being re-used). I think it had something to do with
| readahead buffers being allocated in a different way from normal buffers.
+---------------

Close. The actually policy is: When releasing a just-read block to
the free list (after the copy to the user is done), if you see that the
block was read-ahead [past tense: "RED-ahed"] (that is, caused to be read
not directly by the user but by the read-ahead strategy in the filesystem),
release the block to the FRONT of the free list, not the end. This causes
long sequential reads to flip back and forth using the first two blocks of
the free list, leaving the others alone. This applies to ALL sequentially-
read files, not just programs. (Incidentally, the first two blocks of a
sequential file will stay in the cache. Exercise for the reader: Why TWO?)

This is very useful in small v7-style systems with relatively slow access-time
disks (such as stepper-motor-poistioner winchesters), although the usefulness
in other, larger systems is not known. Do not blindly expect it to improve OR
harm things in your configuration. It seems mostly useful in multi-user systems
with a lot of "database"-style activity, such as business applications and
word-processing, where many directory traversals occur. It can actually
decrease slightly the performance of a single-user system, since even trivial
programs must be re-read from disk (unless they are 2K or less!). On the other
hand, in an environment where many of the "programs" are small shell scripts,
things may get better (especially if you "sticky-text" the shell). Since
the strategy is implemented at the block-driver level (roughly), even long
directories will fail to have their higher blocks cached (although, from
above, blocks 0 & 1 WILL be).  Whether this is good or bad depends on your
configuration.

This policy was suggested by yours truly, implemented by Rick Kiessig, and
reviewed, discussed, and criticized by Dave Yost, John Bass, Bakul Shah, and
others. (None of those mentioned are currently with Fortune Systems, though.)

Rob Warnock

UUCP:	{ihnp4,ucbvax!amd}!fortune!redwood!rpw3
DDD:	(415)572-2607	(*new*)
Envoy:	rob.warnock/kingfisher
USPS:	510 Trinidad Ln, Foster City, CA  94404	(*new*)