Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!smoke!bzs%bostonu.csnet@csnet-relay.arpa
From: bzs%bostonu.csnet@csnet-relay.arpa (Barry Shein)
Newsgroups: net.unix-wizards
Subject: inode table full
Message-ID: <1938@brl-smoke.ARPA>
Date: Wed, 19-Mar-86 21:24:59 EST
Article-I.D.: brl-smok.1938
Posted: Wed Mar 19 21:24:59 1986
Date-Received: Sat, 22-Mar-86 05:39:38 EST
Sender: news@brl-smoke.ARPA
Lines: 24


There's definitely an inode bug in the original 4.2 tape distribution.
Not sure what the fix is tho it's been discussed a few times on this
list. The way to find out if that is your problem is to use pstat
to determine if any inodes have a ref count of -1 (will, I believe,
appear as ff or 255 on the output of pstat.) If so, you got it and
I believe it can lead to inode table full messages. Temporary fix?
Re-boot and pray for the best, increasing the number of inodes in
the system (as Chris Torek suggested, by upping MAXUSERS) will probably
help (seems to have here at BU) but won't completely cure it tho if
you have the memory it's a fine suggestion (in general it seems like
a good idea to set MAXUSERS in 4.2 to about as high as you can afford
anyhow, increases buffers etc but of course this is a complicated tuning
issue, well, not so complicated but I don't want to go into it here,
suffice it to say if you have 16 users on average and MAXUSERS is 16
and you have at least 4MB of memory you should increase MAXUSERS to
at least 32, I have 8MB on a 750, typically 20 users [I know, ugh!]
and am happy with 48 MAXUSERS, given the memory about double the actual
users is not wild.) This is all kinda irresponsible advice, but maybe
it will point you towards some common sense findings.

	-Barry Shein, Boston University

Me, I'm hoping it will all be fixed in 4.3...hah!