Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!noao!mcdsun!sunburn!gtx!edge!hanko
From: hanko@edge.UUCP (Jim Hanko)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <993@edge.UUCP>
Date: Mon, 23-Nov-87 21:21:55 EST
Article-I.D.: edge.993
Posted: Mon Nov 23 21:21:55 1987
Date-Received: Fri, 27-Nov-87 22:02:58 EST
References: <283@paisano.UUCP> <156@fesk.UUCP> <3626@islenet.UUCP> <986@edge.UUCP> <325@boole.acc.virginia.edu> <3646@islenet.UUCP>
Reply-To: hanko@edge.UUCP (Jim Hanko)
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 81
Keywords: SysV bugs
Summary: Fix diffs, suggestions for work around
Xref: mnetor comp.sys.att:1863 comp.unix.wizards:5593


I must apologize for not responding sooner, but I was put out of action for
a week due to an auto accident. Anyway (some history):

In article <3626@islenet.UUCP> richard@islenet.UUCP (Richard Foulk) writes:
>  ( description of problem of appearing to run out of inodes when there 
>   are actually many free inodes. )

In article <986@edge.UUCP> hanko@edge.UUCP (Jim Hanko) [that's me] writes:
> (description of fix)

In article <325@boole.acc.virginia.edu> slb@boole.acc.virginia.edu writes:
> ....  So, it seems to me that the problem could only arise when
>there were exactly enough inodes left between the starting point and the
>end to fill the cache (any less and you'd reset the starting point, any
>more and there'd be one to find on the next search) the last time around.
>But it doesn't seem as though this could arise often enough to account
>for how often I see it.  What am I missing?  (if it's obvious, please
>be kind ...)

It has been almost a year since I fixed this bug, so I had forgotten some
of the details of the problem.  It is true that this will only occur when
exactly NICINOD free inodes were left from the starting point of the 
last successful search.  This seems to occur more often than you might expect
on a file system that is very active (e.g. net news). I believe it happens
when you start using inodes near the end of the inode table.  For example,
if a file is deleted and its inode is approximately NICINOD from the end,
and if this is the last inode re-allocated from the cache, the next group
of inodes found will be near the end.  If many files are then created and 
deleted in rapid fire, chances are good that the situation will show up.

In article <3646@islenet.UUCP> richard@islenet.UUCP (Richard Foulk) writes:
>So the question is: do you have diffs for the fix?

I am a little uncomfortable about posting diffs, so I will try to do so without
giving too much detail.

=== in module ialloc() ===
<	fp->s_ninode = NICINOD;
<	ino = ...
<	for(adr = ... {
<		.
<		.	<-- major loop which searches for free inodes
<		.
<	}
---
>
>again:	/* come back here if necessary to re-search from beginning */
>
>	fp->s_ninode = NICINOD;
>	ino = ...
>	for(adr = ... {
>		.
>		.	<-- major loop which searches for free inodes
>		.
>	}
>	/*
>	 *	If we didn't find any and we didn't start at the beginning,
>	 *	look again starting at the beginning
>	 */
>	if (fp->s_ninode == NICINOD && fp->s_inode[0] != 0) {
>		fp->s_inode[0] = 0;
>		goto again;
>	}
---

I don't generally like using 'goto's, but it seemed the least intrusive
way to fix the problem (please, no flames).

In article <3646@islenet.UUCP> richard@islenet.UUCP (Richard Foulk) writes:
>Since only rnews seems to provoke this bug is there some sort of
>way to avoid the bug that comes to mind?

The only thing I can suggest is to have so many free inodes that you rarely
go near the end of the table.  I'm not sure how much that will help, though.

---
Jim Hanko		...{mot|ism780|oliveb}!edge!hanko
Edge Computer,
Scottsdale AZ
--