The INfamous inode bug

[Larry Jones]

In article <1991Jan15.201410.18885 at eci386.uucp>, woods at eci386.uucp (Greg A. Woods) writes:
> Then again, those of us who do the old resource utilization
> calculations and predictions never exercise the bug in the first
> place.  Even with a 100 Mb news spool I've never run out of inodes,
> and thus I don't know if any system I use has ever had the bug!

You've misunderstood -- no amount of calculation and checking can
protect you from the inode bug.  The problem is that, under certain
conditions, the system CLAIMS that there are no free inodes when,
in fact, there can be arbitrarily many.  When the bug hits, you can
instantly go from having hundreds (or even thousands) of free inodes
to zero.  The necessary conditions are a certain pattern of
allocations and frees -- it is sufficiently obscure that I'm a bit
surprised that anyone ever hits it, but they do.  And some hit it
quite often.

I've never had the problem myself, but I believe in preventive
measures.  When Bill Wells posted the patch for Microport
System V/386, I looked at the code and the patch and decided
that it was a reasonable fix and applied it.  When I switched
to ISC 2.0.2 and discovered it had the same problem, I again
applied Bill's patch.  When I got the update to 2.2 and found
out that ISC's fix didn't quite fix the problem, I again
looked at the code, developed a modified patch, and applied
it.

So, for those who have expressed reservations about apply binary
patches obtained from the network (a healthy dose of paranoia is
good for any system manager) -- I can personally vouch for the
Microport 386 and ISC 2.0.2 and 2.2 patches.  Of course, you
don't know me, but you do have my name, address, phone number,
and net address! :-)

Of course, it doesn't matter to me whether you apply the patches
of not.  That's a decision that you will have to make for youself
based on your perception of the severity of the problem, the
liklihood of it occurring, the consequences of its occurring,
the liklihood of there being some problem with the patch, and
the potential consequences of a problem with a patch.  For what
it's worth, my evaluation of my situation is that the severity
of the problem is fairly low -- the chances of it happening is
very small and the consequences are not great since my system
is basically single user and my news comes via NFS from another
machine, I don't have a direct feed.  Running fsck would take
a while, but would fix the file system.  On the other hand, the
patch is fairly small and the affected routine (s5ialloc) is
also fairly small.  I was able to understand the affected code
and the patch fairly easily and convince myself that it was a
reasonable solution to the problem, so I decided to install it.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
Domain: scjones at thor.UUCP  Path: uunet!sdrc!thor!scjones
I just can't identify with that kind of work ethic. -- Calvin