woods@eci386.uucp (Greg A. Woods) (01/16/91)
In article <114@thor.UUCP> scjones@thor.UUCP (Larry Jones) writes: > Your have a valid point, but at least Interactive TRIED to fix the > problem. AT&T has known about this bug for heaven-only-knows how > long and they've just finally gotten around to fixing it for R4. > And who knows if their fix is really right or not?!? 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! Careful tuning of the news software will also usually prevent you from even running out of blocks. Further checks can prevent you from ever running out of inodes too. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
scjones@thor.UUCP (Larry Jones) (01/18/91)
In article <1991Jan15.201410.18885@eci386.uucp>, woods@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@thor.UUCP Path: uunet!sdrc!thor!scjones I just can't identify with that kind of work ethic. -- Calvin