rd@tarpit.UUCP (Bob Thrush x210) (04/26/89)
[ 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@tarpit.UUCP> >Date: 17 Apr 89 01:42:16 GMT >Reply-To: rd@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@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