Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!shelby!msi.umn.edu!cs.umn.edu!quest!ssb
From: ssb@quest.UUCP (Scott Bertilson)
Newsgroups: comp.sys.3b1
Subject: Re: v01i002:  Kernel configuration files, version 2, Part01/01
Message-ID: <1991Feb16.053842.23496@quest.UUCP>
Date: 16 Feb 91 05:38:42 GMT
References: <1348@galaxia.Newport.RI.US>
Organization: Quest Research, Inc.
Lines: 22


  For what it's worth, the kernel on the 3b1 has an inode table, not
a true cache...in the sense that entries are only valid as long as
some process is still using that inode.  This contrasts with a true
SVR2 or SVR3 system where the entries are still valid and can be
reclaimed by a future access to that inode.  This can be demonstrated
using "crash" (there is a PD XENIX version that partially works on
the 3b1) because on the 3b1, the "i_number" element of the structure
gets set to 0 thus destroying the entry whereas on SVR[23], the
reference count goes to 0, but "i_number" doesn't so the entry can
be found on a later scan.
  I only mention this from the standpoint that on SVR[23], it pays
to make the inode table oversize since it is a true cache.  I
checked this out awhile back because I decided to trim my inode
table down to a more reasonable size for a single user machine
(It was set to 400, I've now got 70 more buffers instead).
  I would be delighted to find out I'm wrong, but I've
checked it very carefully.
-- 

Scott S. Bertilson   ...ssb@quest.UUCP
			scott@poincare.geom.umn.edu