pax@cs.fau.edu (Garry M. Paxinos) (11/21/90)
We have an system installed at a customer site that has been operational for a few years. As this is at an insdustrial site and has not had any other problems, we have been rather reluctant to upgrade the OS... Recently, the free inode count on the root partition started to decrease until about a week ago the count dropped to zero. Obviously the system is now not operating... I have verified that it is not our software by: deleting some unused files in the root file system (so there were some free inodes to start with,) and made sure that our software was not operating. After a day I called back in and the free inode count was again zero. Before and after comparisons of an 'ls -laR /' did not show anything usefull. Does anyone have an idea of what is causing this and where the inodes have gone? I'd like to solve this without recreating the root file system as this would involve a cross country service call for my company (we're in South Florida and their in Washington state.) Thanks for any suggestions.. Take care, Garry. pax@megasys.com
cpcahil@virtech.uucp (Conor P. Cahill) (11/23/90)
In article <1990Nov20.164220.9662@cs.fau.edu> pax@cs.fau.edu (Garry M. Paxinos) writes: >Recently, the free inode count on the root partition started to decrease >until about a week ago the count dropped to zero. Obviously the system >is now not operating... This is a known problem in just about all system V OSs. The problem is that the OS thinks the free inode count goes to zero when it really doesn't. Binary patches have been posted, but I don't think any of them were for 386/ix 1.0.6. The problem is associated with alot of file creations and deletions on a system (from your post I would guess that you are creating lots of files in /tmp or some other portion of the root file system). One solution would be to put these files on another partition and on a nightly basis (or whenever it is needed) unmount, fsck, and then remount the partition. >Does anyone have an idea of what is causing this and where the inodes >have gone? I'd like to solve this without recreating the root file >system as this would involve a cross country service call for my >company (we're in South Florida and their in Washington state.) You should be able to fix this by rebooting the system and fscking the root partition while the machine is coming up. You can force this by modifying the /etc/bcheckrc file (I don't have 1.0.6, so your file name may be different) so that it always runs an fsck when the system boots. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
pax@megasys.com (Garry M. Paxinos) (11/26/90)
In article <1990Nov23.131138.5137@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: In article <1990Nov20.164220.9662@cs.fau.edu> pax@cs.fau.edu (Garry M. Paxinos) writes: >Recently, the free inode count on the root partition started to decrease >until about a week ago the count dropped to zero. Obviously the system >is now not operating... This is a known problem in just about all system V OSs. The problem is that the OS thinks the free inode count goes to zero when it really doesn't. Binary patches have been posted, but I don't think any of them were for 386/ix 1.0.6. The problem is associated with alot of file creations and deletions on a system (from your post I would guess that you are creating lots of files in /tmp or some other portion of the root file system). Hi Conner, Thanks for the advice, but I've been bitten many times by the inode problem you mention while running news for the past 5 years... Unfortunately that is not the problem. In the original post, I mentioned that only the operating system was running and the our applications were not running. Also, the system only has one uucp connection (to us) and does not get any news. Also, fsck does not reclaim the lost inodes and as I stated before comparing an 'ls -laR /' from one day to the next does not show anything signifcant... the inodes are just gone... Take care, Garry. -- E-Mail:pax@megasys.com pax@ankh.ftl.fl.us g.paxinos@compmail.com USNail:Megasystems, Inc. 2055 South Congress Ave, Delray Beach, FL 33445 UUCP :{gatech!uflorida!novavax!ankh, mthvax, herctec, attmail}!megasys!pax Voice :407-243-2405 Data: 407-243-2407 Fax: 407-243-2408 Telex: 156281499 "This is America, Right?!?!?" member of 2 Live Crew