From owner-freebsd-hackers  Tue Dec 16 22:41:58 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA15561
          for hackers-outgoing; Tue, 16 Dec 1997 22:41:58 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA15554
          for <freebsd-hackers@freebsd.org>; Tue, 16 Dec 1997 22:41:51 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id RAA01913;
	Wed, 17 Dec 1997 17:05:39 +1030 (CST)
Message-Id: <199712170635.RAA01913@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: sclawson@bottles.cs.utah.edu (steve clawson)
cc: ivt@gamma.ru (Igor Timkin), tlambert@primenet.com,
        freebsd-hackers@freebsd.org
Subject: Re: panic: blkfree: freeling free block/frag 
In-reply-to: Your message of "Tue, 16 Dec 1997 22:13:01 PDT."
             <199712170513.WAA03545@bottles.cs.utah.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 17:05:38 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>      I've been getting ``freeing free block'' panics fairly often when
> our main server is doing a bunch of large compiles.  A couple weeks
> ago I finally caught it in the act.  One of my compiles died and I
> found a source file with exactly 8k of gunk, sitting nicely on an 8k
> boundary (this was on an 8k/1k filesystem).  The interesting thing
> about the file was it's list of direct blocks:
> 
> 0: 179bb8
> 1: 179bc0
> 2: 179bc8
> 3: 179bd0
> 4: 179bd8
> 5:  79be0
> 6: 179be8
> 7:      0
> 
>      All nicely clustered...except for that sixth one.  At first I
> thought that the clustering code was at fault, but disk block 79be0
> was untouched, and the `real' disk block (179be0) had the correct data
> for the new file.  So, the list of blocks in the inode was corrupted
> sometime after the data blocks for the file were written.

Single-bit memory error, perhaps?  Still, keep an eye on it...

mike