Xref: utzoo comp.unix.wizards:5908 comp.mail.misc:752 news.software.b:1047
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!uvaarpa!virginia!scl
From: scl@virginia.acc.virginia.edu (Steve Losen)
Newsgroups: comp.unix.wizards,comp.mail.misc,news.software.b
Subject: Re: Another way that news eats inodes (THE ANSWER!)
Message-ID: <534@virginia.acc.virginia.edu>
Date: 29 Dec 87 17:53:20 GMT
References: <440@minya.UUCP> <375@octopus.UUCP>
Reply-To: scl@virginia.edu
Organization: University of Va., Charlottesville, VA
Lines: 47


In case y'all missed it, there was a massive discussion of this
news-eats-inodes problem in comp.sys.att about 2 months ago.

The problem is a bug in the Sys V kernel.  The kernel keeps a cache
of free inode numbers in the superblock.  When the cache empties, the
kernel searches the ilist for more free inodes to put in the cache.
The kernel searches the ilist starting at the last inode number
that was taken from the cache.  If the end of the ilist is encountered without
finding any free inodes, the kernel assumes there are no free inodes and
sets the inode count to zero.  (The kernel should wrap its search
back to the top of the ilist here.)

The following scenario will cause a SysV file system to lose all its free inodes.

1. System takes last inode from cache.  There are probably plenty of free inodes
   still in the ilist, though.

2. System frees an inode whose number is higher than any other free inode in ilist.
   This inode goes into the previously empty cache.

3. System needs an inode taking last inode from cache.

4. System needs another inode.  Cache is empty so system tries to refill the cache.
   System starts searching ilist at number of last inode taken from cache
   (which was beyond any free inodes in ilist).

5. System hits end of ilist without finding any free inodes so free inode
   count set to 0. :-(

All SysV file systems are susceptible to this bug, but it only appears in news
file systems because they create and delete so many files.  Since the cache
holds 200 inumbers, most "normal" file systems rarely empty it.  News
file systems get their caches drained often and it's never clear
where the search to refill the cache will start.  Thus news file systems
eventually allocate their highest-numbered inodes even though they never
use more than about half of their available inodes.  This spells disaster
further down the road.

For those of you with kernel source you can fix the problem in the ialloc()
routine.  And for those with rel 3. it is in 5ialloc() or somesuch.

Many thanks to the persons who posted the solution to this problem earlier.
I am only passing on their information and regret that I don't have their
names to give them due credit.
-- 
Steve Losen
University of Virginia Academic Computing Center