Date: Sun, 10 Sep 95 13:15:37 EDT From: jleppek@suw2k.ess.harris.com (James Leppek) To: freebsd-current@freefall.FreeBSD.org Subject: Re: Sig 11 and -current problems. Message-ID: <9509101715.AA01611@borg.ess.harris.com>
next in thread | raw e-mail | index | archive | help
That makes sense, and also explains why walking thru the build works because it would change what information is paged and when it would be flushed, you hope for enough faults to flush the bad data out before it gets touched :-). The strange part is that my latest build is still running??? I would have thought to see a fairly deterministic failure once the VM and cluster changes had been incorporated. Oh well... Jim (its still compiling) Leppek > From owner-freebsd-current@freefall.freebsd.org Sun Sep 10 12:56:40 1995 > To: jleppek@suw2k.ess.harris.com (James Leppek) > Cc: freebsd-current@freefall.freebsd.org > Subject: Re: Sig 11 and -current problems. > From: David Greenman <davidg@Root.COM> > Reply-To: davidg@Root.COM > Date: Sun, 10 Sep 1995 09:54:40 -0700 > Sender: current-owner@FreeBSD.org > > >I do not think there is a "one pass" solution for the current problem. > >I am also a little puzzled as to how the VM changes(if they are at fault) > >can cause such pervasive problems??? I would have thought they would > >be isolated inside the kernel and outside of most of the binaries... > > Among John's changes were some to the way that fault clusters work. When the > system does clustering, it must determine the number of contiguous blocks on > the disk. If it calculates this number too large, it will page in some garbage. > Once this gets paged in, it will "stick" in the cache until it is flushed. The > affect of this is that machines with lots of memory will tend to work better > than machines with small amounts of memory (because the small memory machines > will flush out the garbage quickly and/or do less aggressive clustering - > avoiding the problem completely). > The problem *might* be in the new ffs_bmap() routine that now calculates > the amount of "run behind" (the amount of contiguous pages before the > requested block). In any case, the problem sounds very much to be either in > the vnode_pager or related routines (ffs_bmap, etc). I don't have time to look > into this at the moment, but perhaps John will be able to some time soon. > > -DG >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509101715.AA01611>