Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ucbcad!ucbvax!decvax!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <355@minya.UUCP>
Date: Sun, 8-Nov-87 08:58:30 EST
Article-I.D.: minya.355
Posted: Sun Nov  8 08:58:30 1987
Date-Received: Wed, 11-Nov-87 02:37:17 EST
References: <283@paisano.UUCP> <4259@sdcsvax.UCSD.EDU>
Organization: home
Lines: 40
Keywords: 3b2 inode file system
Summary: This is a Sys/V problem...
Xref: mnetor comp.sys.att:1700 comp.unix.wizards:5387

In article <4259@sdcsvax.UCSD.EDU>, brian@sdcsvax.UCSD.EDU (Brian Kantor) writes:
> 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.

You folks are just discovering a common (possibly universal) Sys/V bug.
I've been able to produce this behavior on numerous machines that were 
clearly running different ports of Sys/V.  It seems to have little to
do with exactly what the software was doing.  The kernel just loses track
of inodes (and also blocks).  The situation with blocks is fairly easy
to understand:  If a block isn't in any file, and isn't on the free
list, the kernel can't find it.  All it takes is someone zeroing out
a buf[] pointer without first freeing the block.

For inodes, you'd think that it couldn't happen, since the kernel can
determine by examination which inodes are free, and they are a simple
vector.  But in Sys/V, free inodes are also in a linked list, so the
kernel is dependent on inodes being freed properly.  In this case, it
should be simple to write an "inode scavenger" to correct the problem
on the fly.  But you'd have to put it in the kernel, because the kernel
caches critical info (such as recently-allocated inodes, which would
appear "unallocated" on the disk because the in-memory copies haven't
been flushed).

Anyhow, it may or may not be a consolation to know that many Sys/V
releases have the same problem.  Whether AT&T knows about it, I don't
know.  Maybe we should tell them that we know....

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)