Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <8957@utzoo.UUCP>
Date: Tue, 17-Nov-87 21:54:24 EST
Article-I.D.: utzoo.8957
Posted: Tue Nov 17 21:54:24 1987
Date-Received: Tue, 17-Nov-87 21:54:24 EST
References: <283@paisano.UUCP> <4259@sdcsvax.UCSD.EDU> <355@minya.UUCP> <33319@sun.uucp>, <2043@killer.UUCP>
Organization: U of Toronto Zoology
Lines: 21
Keywords: 3b2 inode file system

> ...the difference between Version 7 and later versions ( > System III )
> is the free inode count is maintained in the superblock...
> ... Now, the kernel `knows' how
> many free inodes are out there without even looking.

Given that it doesn't know *where* they are, how is this useful?  The only
situation in which knowing the count is significant is when a filesystem
is out of inodes, or so close to it that the search for more can be cut
short by the count.  Now the $64 question:  how frequent is this?  Not very,
in my experience.  In fact, I'm not sure I've ever seen it.  I question the
value of an "optimization" for such a rare case that introduces bugs in more
common situations, which is obviously the case here.

P.S. My kernel maintains the inode count, but only for human contemplation;
	the kernel itself pays no attention to it.

P.P.S. Whatever the bug is, it must be something that AT&T added since V7,
	since my system never loses inodes.
-- 
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry