Bring up Reno

Dennis Ferguson dennis at gpu.utcs.utoronto.ca
Fri Apr 12 02:40:29 AEST 1991


In article <1926 at hslrswi.hasler.ascom.ch> mwm at 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));
  }
  
  /*



More information about the Comp.bugs.4bsd.ucb-fixes mailing list