Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: news.admin
Subject: Re: The Inode-Eating Bug
Message-ID: <1989Oct9.140605.21949@twwells.com>
Date: 9 Oct 89 14:06:05 GMT
References: <906@zorch.SF-Bay.ORG> <231@rsiatl.UUCP> <1989Oct7.213314.17921@twwells.com> <282@rsiatl.UUCP>
Organization: None, Ft. Lauderdale, FL
Lines: 51

In article <282@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. De Armond) writes:
: In article <1989Oct7.213314.17921@twwells.com> bill@twwells.com (T. William Wells) writes:
: >Apologies, but your scripts do little or nothing to solve the problem.
: >
: >First: the inode crash can occur regardless of the number of available
: >inodes on your system.
: >
: >Second: the crash can occur almost instantly after you have done a
: >fsck, so doing it frequently does not eliminate the problem.
: >
:
: Please cite an example of how a crash can occure right after an fsck.

I had the following experience:

	run out of inodes
	fsck the file system
	restart the news job
	run out of inodes
	fsck the file system
	restart the news job
	run out of inodes
	fsck the file system
	restart the news job
	run out of inodes
	fsck the file system
	do some random file creates and deletes to change the inode cache
	restart the news job
	phew! it worked

So the answer is: it has happened.

: From a practical perspective, these scripts have reduced the inode problem
: on stiatl at my former employer from perhaps twice daily on the news partition
: to NEVER. (We were forced to run a tight disk so we are close to the
: hairy edge most of the time).  On rsiatl here, the scripts have also
: totally eliminated the problem.  That's kinda the bottom line.

Well, you've been lucky. I suppose that running fsck frequently would
reduce the probability of the crash; the bug *can* result in gradual
loss of inodes. But the bug can also result in catastrophic loss of
inodes and your scripts won't protect you against that.

Do yourself a favor and get one of the real fixes. Among other things,
they don't cost anywhere near as much CPU time or disk activity or
downed file system time. And they *completely* eliminate the
possibility of this particular crash.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com