Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!umd5!uvaarpa!virginia!boole!slb
From: slb@boole.acc.virginia.edu (sandy)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <325@boole.acc.virginia.edu>
Date: Wed, 18-Nov-87 19:55:10 EST
Article-I.D.: boole.325
Posted: Wed Nov 18 19:55:10 1987
Date-Received: Sat, 21-Nov-87 15:15:22 EST
References: <283@paisano.UUCP> <156@fesk.UUCP> <3626@islenet.UUCP> <986@edge.UUCP>
Reply-To: slb@boole.acc.virginia.edu
Organization: University of Va., Charlottesville, VA
Lines: 46
Keywords: SysV bugs
Xref: mnetor comp.sys.att:1810 comp.unix.wizards:5517

In article <986@edge.UUCP> hanko@edge.UUCP (Jim Hanko) writes:
>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. )
>I ran into the same probem on our news file system and tracked it down
>to a generic System V bug in the ialloc() module.  The problem occurs
>because ialloc() scans from the last inode allocated to the end of the
>inode table looking for free inodes.  If none are found (e.g. if the
>last allocated inode was near the end of the table and all subsequent
>ones are in use), then "out of inodes" is reported.  It DOES NOT go
>back to search for free inodes from the beginning.  Therefore, this
>error can occur even when many free inodes are available. 
>
>The fix involves checking whether the search began at inode 0 when no free
>inodes were found.  If it didn't, then re-start the search at 0. If it
>did, THEN print "out of inodes" and exit. 
>
>This problem rarely shows up on "normal" file systems, but the high level
>of activity in net file systems seems to aggrivate it. 

This sounds good - we have this problem frequently, so I checked out
the source that we have (SVR2 and SVR3).  It's true that whenever you
have to replentish the free inode cache, you search through the inode
list starting wherever you left off last time.  And it's also true that
you only search to the bottom of the list - you don't wrap around.  But
there is also code there to reset the starting point to zero whenever
you managed to find a few free inodes, but not enough to totally fill
the cache.  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 ...)

And another thing - how come an fsck fixes it?  I can see how it
resets the free inode count so you no longer think you're out of
inodes, but it doesn't seem to reset the starting point for the
search (at least a brief search through fsck.c turns up no obvious
references to that field).  Wouldn't you just have the same problem
the next time you alloc'ed an inode?  Does mount reset this?

-- 
sandy bryant
slb@virginia.edu
uunet!virginia!slb