Xref: utzoo comp.unix.questions:14039 comp.unix.wizards:16659
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!ncrcae!wescott
From: wescott@ncrcae.Columbia.NCR.COM (Mike Wescott)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Request for summarized inode problem
Keywords: inodes
Message-ID: <4550@ncrcae.Columbia.NCR.COM>
Date: 5 Jun 89 13:18:29 GMT
References: <1217@swusrgrp.UUCP>
Reply-To: wescott@ncrcae.Columbia.NCR.COM (Mike Wescott)
Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC
Lines: 24

In article <1217@swusrgrp.UUCP> jeff@swusrgrp.UUCP (Jeff Tye sys adm) writes:
> [...] could somebody
> please tell me in a short paragraph or two about what causes the inode table
> to get crashed when running news.

It's not news that does it, at least not directly.  It is a kernel bug.
The SysV kernel keeps track of the lowest unused inode, in order to improve
the scan time to find new inodes.  There is, however, a bug whereby the kernel
can free up an inode that is lower than the current "lowest" and not update
its current concept of lowest inode.  Since searches for unused inodes begin
with this "lowest" inode, others that are lower in number can be "lost".
The pattern of additions and deletions to the filesystem caused by news
seems to exacerbate the problem.

> Is there a fix on the horizon?

Your vendor should have a fix by now.  ialloc() in alloc.c can be changed to
rescan the inode list from the beginning one more time if the kernel finds
that it has run out of inodes.

	-Mike Wescott
-- 
	-Mike Wescott
	 mike.wescott@ncrcae.Columbia.NCR.COM