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: <326@boole.acc.virginia.edu>
Date: Wed, 18-Nov-87 20:13:45 EST
Article-I.D.: boole.326
Posted: Wed Nov 18 20:13:45 1987
Date-Received: Sat, 21-Nov-87 15:15:55 EST
References: <283@paisano.UUCP> <156@fesk.UUCP> <3626@islenet.UUCP> <986@edge.UUCP> <325@boole.acc.virginia.edu>
Reply-To: slb@boole.acc.Virginia.EDU
Organization: University of Va., Charlottesville, VA
Lines: 16
Keywords: SysV bugs
Xref: mnetor comp.sys.att:1811 comp.unix.wizards:5518

In article <325@boole.acc.virginia.edu> slb@boole.acc.virginia.edu writes:
>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?

I just looked and mount does reset it.  That means that if you can't
fix the source, you might be able to ward off the evil spirits by 
just umnounting and remounting the file system (i.e. you don't have
to reboot or even fsck).
-- 
sandy bryant
slb@virginia.edu
uunet!virginia!slb