Summary "file table full"
I received 2 correct responses, and Yves Hardy gave me a couple of usefull
options to pstat and df.
I determined from his explaination that indeed the kernel needed
maxusers increased from 96 to 128. After rebuilding the kernel
and rebooting, all is well. Lucky for me it was not the disk
inodes that were causing the problem.
- Dec 19 16:24:23 sun3 vmunix: file: table is full
- Dec 19 16:29:06 sun3 last message repeated 7 times
- Dec 19 16:30:15 sun3 vmunix: file: table is full
- Dec 19 16:35:26 sun3 last message repeated 9 times
- Dec 19 16:37:55 sun3 vmunix: file: table is full
Thanks to : email@example.com (Celeste Stokely)
Who also had the correct answer.
------- long explaination. I'll be keeping this --------------
From: firstname.lastname@example.org (Yves Hardy)
Regarding your problem with the your vmunix file: table is full, the
only solution to solve your problem is to increase the inodes table
I show you below a solution you can try to increase the number of
Two types of inodes: kernel and disk. Able to tell
which inode table is full by the message. If getting
this type of message:
vmunix: inode table full
then it is the kernel inode table that is full. Verify
this by running pstat -T:
# pstat -T
Notice that the line for inodes shows that 199 are
being used and the maximum is also 199.
If the disk inode tabel isfull, this message appears:
/:inode table full
Notice the message is referring to a partition (in this
case, root) instead of the kernel. Verify this by
running df -i -t 4.2:
# df -i -t 4.2
Filesystem iused ifree %iused Mounted on
/dev/sd0a 2794 2794 100% /
/dev/sd0g 7007 29857 19% /usr
/dev/sd2h 301 11219 3% /var
/dev/sd2a 30 9954 0% /home
/dev/sd2g 4656 16848 22% /export
Notice that the root partition has used all the
If the disk inode table is full:
- do a dump of the filesystem, as it will have to be
- run newfs -N on the raw disk partition:
# newfs -N /dev/rsd2g
/dev/rsd2g: 92190 sectors in 439 cylinders of 6 tracks, 35 sectors
47.2MB in 28 cyl groups (16 c/g, 1.72MB/g, 768 i/g)
super-block backups (for fsck -b #) at: ....
Notice that this partition has 768 inodes per cylinder
- Make sure the partition is not mounted (if root or
/usr, then this will have to be done from miniroot)
- newfs -i xxx /dev/r<partition> (where xxx is the
number of inodes per cylinder group you want and
<partition> is sd0h, sd1a, etc.)
- Restore the file system from dumps.
NOTE: Prior to 4.1, a maximum of 2048 inodes per
cylinder group existed. To get around this, run:
and increase the number of cylinder groups (increasing
the number of cylinder groups allows more inodes in the
If kernel inode table is full, do ONE of the following:
NOTE: the instructions on configuring a new kernel can
be found in the System and Network Aministration manual.
1) Edit the kernel configuration file. Increase the
MAXUSERS value (rule of thumb: double the current
value). Make and reboot the new kernel.
2) Run config on the kernel configuration file. Then:
- cd /sys/<arch>/conf
- cd /sys/<arch>/<kernel>
(where <kernel> is the name of the configuration file
and <arch> is the kernel architecture.)
- edit param.csearch for the line that contains "ninode"
This line is the formula that calculates the number
of kernel inodes.
- adjust this formula by upping some of
- do a "make" on the kernel, then reboot
the new kernel
Yves Hardy from AB Computers in Belgium.
From: email@example.com (Celeste Stokely)
Subject: Re: table is full
Yes, worry about it. Build a kernel with MAXUSERS set to a higher number,
like 64 or 128.
Unix System Administration Consultant, Stokely Consulting
Voice Line: 415-967-6898 / FAX: 415-967-0160
USMAIL Address: Stokely Consulting
211 Thompson Square / Mountain View CA 94043
- Do I need to worry about these?
- I do not see any real disk activity or memory processes
- other than a few "VI" processes on the system.
- Any help is appreciated.
- This is on a 4/280 Sparc.
- *************** showrev version 1.15 *****************
- * Hostname: "sun3"
- * Hostid: "2440276e"
- * Kernel Arch: "sun4"
- * Application Arch: "sun4"
- * Kernel Revision:
- 4.1.3_U1 (SUN3) #1: Fri Jul 15 14:54:46 EDT 1994
- * Release: 4.1.3_U1
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:17 CDT