Newsgroups: comp.bugs.4bsd Path: utzoo!utgpu!dennis From: dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) Subject: Re: Bring up Reno Message-ID: <1991Apr11.164029.11706@gpu.utcs.utoronto.ca> Keywords: 4.3Reno,bsd Organization: none References: <1926@hslrswi.hasler.ascom.ch> Date: Thu, 11 Apr 1991 16:40:29 GMT In article <1926@hslrswi.hasler.ascom.ch> mwm@hslrswi.hasler.ascom.ch (Mike McGann) writes: >But I am having a bigger problem. It seems to trash a filesystem in some circumstances >to the extent that fsck can't fix it. I only have to run as root, and try to make >gnu emacs 18.55. Suddenly one of the directories disappears just looks like somebody >unlinked it. Ok I run fsck on the filesystem and it acts just like that. We had vaguely similar symptoms. Our machines would crash frequently when the file systems got busy and would come back up with some really ugly file system inconsistancies. This started to happen when we turned on accounting. We found a bug in the accounting code which was causing the routine which checks to see if the file system is full enough that accounting should be turned off to be called on every clock tick, rather than once every 15 seconds as intended. A patch to kern/kern_acct.c follows. I don't think this change actually repaired the more serious problem (which I suspect is some sort of race condition in the file system code) but it did make the symptoms go away, which made us happy. Note too that the Reno version we were having trouble with is a homebrew port to the IBM RT, which may have its own unique set of problems. Dennis Ferguson *** /tmp/,RCSt1000583 Thu Apr 11 21:18:28 1991 --- kern_acct.c Thu Mar 7 18:38:11 1991 *************** *** 113,119 **** acctp = NULL; log(LOG_NOTICE, "Accounting suspended\n"); } ! timeout(acctwatch, (caddr_t)resettime, hzto(resettime)); } /* --- 113,120 ---- acctp = NULL; log(LOG_NOTICE, "Accounting suspended\n"); } ! timeout(acctwatch, (caddr_t)resettime, ! (int)(resettime->tv_sec * hz + resettime->tv_usec / tick)); } /*