Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!noao!mcdsun!sunburn!gtx!edge!hanko From: hanko@edge.UUCP (Jim Hanko) Newsgroups: comp.sys.att,comp.unix.wizards Subject: Re: Wierd 3b inode problem with news. Message-ID: <994@edge.UUCP> Date: Tue, 24-Nov-87 12:02:15 EST Article-I.D.: edge.994 Posted: Tue Nov 24 12:02:15 1987 Date-Received: Sat, 5-Dec-87 10:50:18 EST References: <283@paisano.UUCP> <156@fesk.UUCP> <3626@islenet.UUCP> Reply-To: hanko@edge.UUCP (Jim Hanko) Organization: Edge Computer Corporation, Scottsdale, AZ Lines: 52 Keywords: SysV bugs Summary: Better explanation of bug frequency Xref: mnetor comp.sys.att:1943 comp.unix.wizards:5742 In article <993@edge.UUCP> hanko@edge.UUCP (Jim Hanko) writes: >In article <325@boole.acc.virginia.edu> slb@boole.acc.virginia.edu writes: >> .... So, it seems to me that the problem could only arise when >>there were exactly enough inodes left between the starting point and the >>end to fill the cache (any less and you'd reset the starting point, any >>more and there'd be one to find on the next search) the last time around. >>But it doesn't seem as though this could arise often enough to account >>for how often I see it. What am I missing? ... > > ( vigorous hand waving in lieu of explanation ) After further reflection, I believe I can explain more clearly. 1) The relevant features of the ialloc() algorithm are: - A cache of NICINOD (100) free inodes is maintained. - When the cache becomes empty, a linear scan through the inode table is performed to find free inodes. - When the cache becomes full (due to file deletions), a new (relatively random) scan point is established, based on the last freed inode. - The bug occurs when the scan takes exactly the last NICINOD free inodes in the table. 2) On a 'normal' file system, file creations and deletions are not well correlated, and occur with approximately equal frequency. Therefore, the cache usually contains sufficient free inodes, and the scan is rarely necessary. When it is, typically one short scan from a random point usually takes care of it. Therefore, the bug almost never shows up in this type of file system. 3) A 'net news' file system experiences repeated episodes where many new files are created at once (new articles arrive), intermixed with episodes where many files are deleted at once (articles expire, packed news files deleted). If enough new files are created at once, relative to the number of free inodes, the likelyhood becomes high that a scan from any random point in the table will reach the end. Normally, it will then resume at the beginning. However, on average, 1% of the time (i.e. 1/NICINODE scans) the bug will strike instead. If it doesn't, the periods of file deletion will establish a new (somewhat) random starting point, creating a new opportunity for the bug to appear during the next file creation binge. Therefore, If you don't have a source license and can't install the fix I posted in an earlier article, I can only suggest that you keep a large number of free inodes in your 'net news' file system. This will reduce, but not eliminate, the probability of the bug affecting you. --- Jim Hanko ...{mot|ism780|oliveb}!edge!hanko Edge Computer, Scottsdale AZ --