Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: inode table full error
Keywords: kernel, inodes
Message-ID: <1807@auspex.auspex.com>
Date: 10 Jun 89 20:13:43 GMT
References: <fVqb7#=keith@xanadu.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 36

>I'm afraid my previous posting did not state my problem clear enough.
>The error I was receiving was "inode table full", and sure enough,
>a check with /usr/etc/pstat -T showed that all 226 slots in the
>in-core inode table were taken.

On most recent versions of SunOS, they will almost always all be
reported as full.  Directory name lookup cache entries hold onto the
inode to which the entry refers; however, DNLC entries are considered
"expendable" and will be purged if the system needs an inode table entry
for something more important (i.e., something where it *must* be able to
read in the inode, rather than something where it's just nice to keep it
around).

So even on a system with an inode table with far more entries than are
absolutely *needed* (i.e., one that won't get "inode table full" unless
you do something *totally* ridiculous), you'll probably see a lot of
entries in use.

>I have since rebuilt my kernel with a maxusers value of 100.

That's, umm, a bit extreme.  A fair number of kernel table sizes scale
with "maxusers", so you've got a very large process table, etc..

Try something a bit less extreme, or, if you really do need an inode
table that big, try manually hacking on "param.c" (in
"/usr/share/sys/conf.common/param.c" in SunOS 4.x, somewhere else in
earlier releases) to change the formula used for the initialization of
"ninode".

>I now have 1790 available entries, but there are 1139 occupied slots.
>There seems to be a process, or group of processes which fail to release
>their inodes when they die.

I.e., because so many slots are occupied?  It may just be that the
directory name lookup cache is holding on to a lot of them, as
indicated.