From owner-freebsd-current  Sun Sep 10 10:18:21 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id KAA11766
          for current-outgoing; Sun, 10 Sep 1995 10:18:21 -0700
Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA11760
          for <freebsd-current@freefall.cdrom.com>; Sun, 10 Sep 1995 10:18:18 -0700
Received: from borg.ess.harris.com (suw2k.ess.harris.com) by ess.harris.com (5.x/SMI-SVR4)
	id AA18490; Sun, 10 Sep 1995 13:18:13 -0400
Received: by borg.ess.harris.com (4.1/SMI-4.1)
	id AA01611; Sun, 10 Sep 95 13:15:37 EDT
Date: Sun, 10 Sep 95 13:15:37 EDT
From: jleppek@suw2k.ess.harris.com (James Leppek)
Message-Id: <9509101715.AA01611@borg.ess.harris.com>
To: freebsd-current@freefall.FreeBSD.org
Subject: Re: Sig 11 and -current problems.
Sender: current-owner@FreeBSD.org
Precedence: bulk

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
>