Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!gatech!hubcap!ncrcae!ncr-sd!rancho!rock
From: rock@rancho.uucp (Rock Kent)
Newsgroups: news.admin
Subject: Re: The Inode-Eating Bug
Message-ID: <1989Oct11.073859.6808@rancho.uucp>
Date: 11 Oct 89 07:38:59 GMT
References: <906@zorch.SF-Bay.ORG> <231@rsiatl.UUCP> <1989Oct7.213314.17921@twwells.com> <282@rsiatl.UUCP> <1989Oct9.140605.21949@twwells.com> <8883@galbp.LBP.HARRIS.COM>
Organization: Del Rayo Ranch, San Diego, CA
Lines: 38
In-Reply-To: mhw@wittsend.lbp.harris.com's message of 10 Oct 89 03:47:00 GMT


 John:  John De Armond
 Mike:  Michael H. Warfield
TBill:  T. William Wells

OK, let's see . . .

 John>  [recommends periodically running some scripts]
TBill>  [says they don't address the problem]
 John>  [says cite examples, my scripts have eliminated the problem]
TBill>  [cites an anecdotal example]
 Mike> 	[asks whether TBill was correctly using fsck]

I don't understand the gruesome details of the inode bug and am not
competent to judge whether regular fsck's or other magic can be
expected to compensate for it.  It seems to me, however, that such an
approach is, at best, a band-aid solution.  Six months ago I was
encountering the inode problem one or two times a week and was
fortunate enough to run across an article by T. William Wells in which
he said:

TBill>  S5ialloc (aka ialloc) has a bug. It seems that the code is
TBill>  dependent on the condition that the inode cache always
TBill>  contains the lowest free inode. This is a condition that just
TBill>  can't be met. . . . .  My fix is to ignore a failure to read
TBill>  inodes and try again.  This has the advantage of not requiring
TBill>  a rescan except when the inode pointer gets screwed up.

I got in touch with Mr. Wells and, with his help, incorporated his fix
in my kernel.  The problem has not recurred.  No muss, no fuss, no
wasted cycles, no lost news.

Disclaimer:  I know T. William Wells only over the net and am merely
an appreciative acquaintance.

***************************************************************************
*Rock Kent    rock@rancho.uucp        POB 8964, Rancho Sante Fe, CA. 92067*
***************************************************************************