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 : celeste@xs.com (Celeste Stokely)
Who also had the correct answer.
------- long explaination. I'll be keeping this --------------
From: yves@suntech.abcomp.be (Yves Hardy)
Hi David,
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
inodes :
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
301/582 files
199/199 inodes
67/138 processes
34208/43012 swap
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
available inodes.
If the disk inode table is full:
- do a dump of the filesystem, as it will have to be
wiped out.
- 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
group.
- 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:
newfs -c
and increase the number of cylinder groups (increasing
the number of cylinder groups allows more inodes in the
partition).
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
the values.
- do a "make" on the kernel, then reboot
the new kernel
Best Regards,
Yves Hardy from AB Computers in Belgium.
From: celeste@xs.com (Celeste Stokely)
Message-Id: <9412200139.AA02397@celestial.xs.com>
To: weitzel@burke.com
Subject: Re: table is full
X-Sun-Charset: US-ASCII
Content-Length: 1785
Status: RO
Yes, worry about it. Build a kernel with MAXUSERS set to a higher number,
like 64 or 128.
..Celeste Stokely
Unix System Administration Consultant, Stokely Consulting
EMAIL: celeste@xs.com
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