Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!sdrc!thor!scjones
From: scjones@thor.UUCP (Larry Jones)
Newsgroups: comp.unix.sysv386
Subject: Re: Inode Bug Fix for ISC 2.0.2
Message-ID: <127@thor.UUCP>
Date: 17 Jan 91 19:01:31 GMT
References: <109@thor.UUCP> <285@alderan.uucp>
Organization: SDRC, Cincinnati
Lines: 67

In article <285@alderan.uucp>, chris@alderan.uucp (Christoph Splittgerber) writes:
> I tried the patch for ISC 2.0.2 on two of our machines. On one machine
> the script did run through without any errors. On the other machine
> (ISC 2.0.2 as well but this license in newer) the script fails at the
> checksum test.
> 
> Anyway, I removed this two checksum test, just to see what happens.
> The script runs through and the "compare the list of differences
> against the expected differences" passes without any problems.
> 
> So, what do you think ? Do you think the patch is ok anyway ?

If the differences match the expected differences, the patch is
almost certainly successful.  Checksumming the file first (twice!)
is sort of a belt-and-suspenders approach to making sure that the
patch doesn't screw up someone's system.  If you verify that the
patch does work, perhaps you could post the checksums from your
system so that others with the save version of the code can use
the patch with less concern.

> Anyway, could some kind of soul tell me what the patch actually
> does ?

When you try to allocate an inode, the kernel code first looks at
the field in the file system superblock which records the number
of free inodes.  If this field is zero, then it writes an error
message to the console and returns a failure status.  Otherwise,
it looks at an in-core list of free inodes and, if the list is
not empty, it removes an element from the list and returns it.
If the list is empty, it scans the filesystem looking for free
inodes and adding any it finds to the in-core list until the
list is full or the end of the file system is reached.  If the
end of the file system in reached without finding any free inodes,
the code assumes that the free inode count in the superblock was
wrong and fails; otherwise, it returns a free inode as before.

Instead of always starting the scan at the first inode, there is
an optimization that keeps track of where to start scanning --
there should not be any free inodes before this point.  The bug
is that this condition is not correctly maintained -- it is
possible for there to be many free inodes before the starting
point.  What the 2.0.2 patch does is it changes what happens when
the scan fails -- instead of assuming that the free inode count
in the superblock was wrong, it assumes that it was right so it
resets the scan start point to the beginning of the file system
and redoes the scan.  Thus, if there are any free inodes, it will
find them.

There is a potential problem with this -- if the free inode count
in the superblock is greater than the true number of free inodes
and you really do allocate all of the inodes, the fixed code will
go into an infinite loop scanning for free inodes.  Since this is
kernel code, your system will be locked up until you reboot.  This
is almost certainly an acceptable trade-off, however, since the
bug is known to make the scan start point incorrect, but there are
no known bugs maintaining the free inode count.  The free inode
count can be corrupted by system crashes, but that almost always
causes the count to be too low (which is OK) rather than too high.

Note that the 2.2 patch does not have this problem -- the code
changes ISC made for 2.2 made it possible to have a completely
correct fix so that an incorrect inode count is detected and
reported rather than causing a loop.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
Domain: scjones@thor.UUCP  Path: uunet!sdrc!thor!scjones
Bad news, Mom.  I promised my soul to the Devil this afternoon. -- Calvin