Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!cuuxb!mmengel
From: mmengel@cuuxb.ATT.COM (Marc W. Mengel)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <1405@cuuxb.ATT.COM>
Date: Fri, 20-Nov-87 13:57:33 EST
Article-I.D.: cuuxb.1405
Posted: Fri Nov 20 13:57:33 1987
Date-Received: Mon, 23-Nov-87 03:31:39 EST
References: <283@paisano.UUCP> <156@fesk.UUCP> <3626@islenet.UUCP> <986@edge.UUCP> <325@boole.acc.virginia.edu>
Reply-To: mmengel@cuuxb.UUCP (Marc W. Mengel)
Organization: AT&T-DSD, System Engineering for Resellers, Lisle IL
Lines: 49
Keywords: SysV bugs
Xref: mnetor comp.sys.att:1836 comp.unix.wizards:5543

-

In article <325@boole.acc.virginia.edu> slb@boole.acc.virginia.edu writes:
$In article <986@edge.UUCP> hanko@edge.UUCP (Jim Hanko) writes:
$>In article <3626@islenet.UUCP> richard@islenet.UUCP (Richard Foulk) writes:
...
$>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
$>then "out of inodes" gets printed
...
$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?
...

fsck does *NOT* fix it, it re-fills your free inode cache and does not
affect that pointer.  This means that your search pointer points to
the end of the inode table, and every time your inode cache runs out,
you get the "out of space" error.  Fsck re-fills the inode cache, but
the search pointer never moves from the end of the inode table...
So you see, once you hit the condition of cache-size inodes being after
the search pointer, you get a condition where you falsely run out of
inodes
$-- 
$sandy bryant
$slb@virginia.edu
$uunet!virginia!slb

-- 
 Marc Mengel	

 attmail!mmengel
 ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel