Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!virtech!cpcahil From: cpcahil@virtech.uucp (Conor P. Cahill) Newsgroups: comp.unix.sysv386 Subject: Re: lost inodes under ISC 1.0.6 Message-ID: <1990Nov23.131138.5137@virtech.uucp> Date: 23 Nov 90 13:11:38 GMT References: <1990Nov20.164220.9662@cs.fau.edu> Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill) Organization: Virtual Technologies Inc., Sterling VA Lines: 33 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