Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!sdcsvax!brian
From: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <4259@sdcsvax.UCSD.EDU>
Date: Thu, 5-Nov-87 12:08:01 EST
Article-I.D.: sdcsvax.4259
Posted: Thu Nov  5 12:08:01 1987
Date-Received: Sun, 8-Nov-87 02:31:21 EST
References: <283@paisano.UUCP>
Reply-To: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Organization: UCSD wombat breeding society
Lines: 32
Keywords: 3b2 inode file system
Xref: mnetor comp.sys.att:1676 comp.unix.wizards:5350

In article <283@paisano.UUCP> demasi@paisano.UUCP (Michael C. De Masi) writes:
>
>I'm running usenet on a 3b2/400 Sys V r2.0.1 and ...
>... I noticed that I was getting "out of inode" errors
>when I knew full well there weren't nearly that many files
>in the system.  So I unmounted the news file system, fsck'd
>it, got a "free inode count in superblock (fix?)" message
>back from fsck, told it to fix it, remounted the file system
>and again everything went smoothly until the news volume
>dropped again, and the same thing happened.

I've noticed similar behaviour here on our 3B15 (SysV 2.1.2) with the
news filesystem running out of inodes - a reboot always fixes it.  It
is almost as though the inodes weren't being properly freed after the
news is expired.  I don't think it's hung processes hanging on to the
inode after the directory entry is removed, since I often don't find any
news processes running.

I find it interesting that the reboot (without an fsck, since the
filesystem was marked as clean when the system went down) fixes the
problem.  If it were truely a buggered superblock, one would not expect
that.

Since news is the one system we run on this machine which creates
multiple links to files, I suspect it might be related to that.

My workaround is to simply schedule a reboot each Monday morning at 3 am.  
That way the system is fresh and clean when I get to work that
week.  Admittedly, that's fixing the symptom and not the problem.

	Brian Kantor    UCSD Office of Academic Computing
			Academic Network Operations Group UCSD B-028,
			La Jolla, CA 92093 USA