ssb@quest.UUCP (Scott Bertilson) (02/16/91)
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
mdapoz@hybrid.UUCP (Mark Dapoz) (02/19/91)
In article <1991Feb16.053842.23496@quest.UUCP> ssb@quest.UUCP (Scott Bertilson) writes: > 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. . . > I would be delighted to find out I'm wrong, but I've >checked it very carefully. Just to confirm Scott's observations, I've also found that the in core inode entries are flushed when the last process to have the file open performs a close. -- Mark Dapoz mdapoz%hybrid@cs.toronto.edu mdapoz@torvm3.iinus1.ibm.com Finger and toes, finger and toes, forty things we share, forty one if you include the fact that we don't care. - The Tragically Hip