Vanishing inode fix for System V/AT

[Bob Thrush x210]

[ Since the original article didn't make it to the West Coast and
  I haven't had any comments, I'm reposting.  If you've already
  seen this posting, please excuse... ]

>Newsgroups: comp.unix.microport
>Subject: Vanishing inode fix for System V/AT
>Message-ID: <2270 at tarpit.UUCP>
>Date: 17 Apr 89 01:42:16 GMT
>Reply-To: rd at tarpit.UUCP (Bob Thrush x210)
>Organization: Automation Intelligence,Inc; Orlando,FL
>Lines: 37


  I believe I now have a fix for the System V/AT "vanishing inode"
problem.  I was continually frustrated when the news file system would
suddenly lose 2-5000 inodes.  Not to mention the dance that fsck may
do on the free list under certain circumstances.  

  As many people are aware, (thanks to teemc!wayne & bill at twwells.uucp
for mail and postings), System V/AT has the dreaded vanishing inode
problem.  The culprit is the ialloc() function which tries to remember
the lowest free inode to improve performance.  Since ialloc doesn't 
always get this right, your system will mysteriously run out of inodes
when there really are some free.  The fix I made is the same as many
others, ie. when the normal ialloc algorithm thinks that it's out 
of inodes, look at superblock->s_tinode.  If s_tinode > 0, then
restart the inode scan, rather than failing.

  I reverse-compiled alloc.o so that the source generated an identical 
object and then added 5 lines of code to implement the fix.  I have 
been running the corrected alloc.o since March 28 and have had about 
a dozen occurences indicating that the new alloc.o is working correctly.  
Since alloc.o was at Rel. 1.3.8, I expect that the corrected version 
will work with systems earlier than 2.4.

  Now for my problem.  I am reminded that it would be illegal for me
to post my reverse-compiled source of this copywright material.  Is it
also illegal to post the object?  If so, would anybody trust it
without the source? :-) :-) (If Microport is reading this, I would be
happy to pass along the required change.)  I will make this fix
generally available after I make certain that there are no legal
objections.  Comments?

  Now, if I can just get an unbroken fsck and a more efficient
serial driver (hardware flow control, 16550 enhancements) ...
-- 
Bob Thrush                 UUCP: {rtmvax,ucf-cs}!tarpit!rd
Automation Intelligence,   1200 W. Colonial Drive, Orlando, Florida 32804