keith@xanadu.COM (Keith Farrar) (06/10/89)
First: Thanks to Melinda Shore, John Grzesiak, and Guy Harris for their suggestions. 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. I have since rebuilt my kernel with a maxusers value of 100. 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. The first candidate seems to be TOPS: I have been using tops to back up the data on my pc. When the ~180 files have been xferred to my unix directories, another 230-300 entries pop up in the table. (this is using TOPS for sun4 on another server, and NFS) These inodes are all under my uid, so I assume they are a side effect of the xfer. Any Ideas, Hints, Suggestions? (Please?) Keith Farrar
guy@auspex.auspex.com (Guy Harris) (06/11/89)
>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.