Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!mimsy!umd5!uvaarpa!virginia!scl
From: scl@virginia.acc.virginia.edu (Steve Losen)
Newsgroups: comp.sys.att
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <495@virginia.acc.virginia.edu>
Date: Tue, 10-Nov-87 10:20:30 EST
Article-I.D.: virginia.495
Posted: Tue Nov 10 10:20:30 1987
Date-Received: Sat, 14-Nov-87 05:58:20 EST
References: <283@paisano.UUCP> <156@fesk.UUCP>
Reply-To: scl@virginia.UUCP (Steve Losen)
Organization: University of Va., Charlottesville, VA
Lines: 38

In article <156@fesk.UUCP> sverre@fesk.UUCP (Sverre Froyen) writes:
>
>I have seen the same thing on an ICM3216 running SysV.2.2.
>The inode count of the spool file system (where news reside)
>will drop from 12000 to 0 within minutes (perhaps seconds) while
>unpacking a compressed news batch (rnews -U). Recourse is to go
...
>-- 
>Sverre Froyen
>UUCP:   boulder!fesk!sverre, sunpeaks!seri!fesk!sverre
>ARPA:   froyen@nmfecc.arpa
>BITNET: froyen@csugold.bitnet

We have 10 3b15's running news and usually at least one of them has
a hosed /usr/spool.  We fix the problem by running fuser -k and then
unmounting /usr/spool to fsck it.  This rarely kills off user processes
but always blows away cron and lpsched.  No problem, we just restart
them from /etc/rc.d.

The fsck recovers from 12,000 to 13,000 free inodes.  This looks suspiciously
like the kernel is stuffing the free inode count into a short int or
passing it to a routine expecting a short, or using 16-bit arithmetic operators.
If the inode count > 2**15, putting it in a short makes it negative!
Has anyone found such a bug in the kernel?  Could it be a more subtle problem?
I once used a FORTRAN compiler that stored small integer constants in shorts
and used 16-bit arithmetic whenever all the operands were short.  Needless to
say, I was quite surprised when the statement

i = 10 * 4000

assigned a negative number to i (where i was declared INTEGER*4, i.e., long).

At any rate, my first guess is that this bug is caused by an erroneous use
of 16-bit operators on a 32-bit quantity.  The problem could be in the C code
or in the compiler.
-- 
Steve Losen
University of Virginia Academic Computing Center