From owner-freebsd-hackers Tue Dec 16 21:13:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA09225 for hackers-outgoing; Tue, 16 Dec 1997 21:13:26 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA09215 for ; Tue, 16 Dec 1997 21:13:17 -0800 (PST) (envelope-from sclawson@bottles.cs.utah.edu) Received: from bottles.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id WAA05905; Tue, 16 Dec 1997 22:13:02 -0700 (MST) Received: by bottles.cs.utah.edu (8.6.10/utah-2.15-leaf) id WAA03545; Tue, 16 Dec 1997 22:13:01 -0700 From: sclawson@bottles.cs.utah.edu (steve clawson) Message-Id: <199712170513.WAA03545@bottles.cs.utah.edu> Subject: Re: panic: blkfree: freeling free block/frag To: ivt@gamma.ru (Igor Timkin) Date: Tue, 16 Dec 1997 22:13:01 -0700 (MST) Cc: tlambert@primenet.com, ivt@gamma.ru, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199712161442.RAA24936@crocus.gamma.ru> from "Igor Timkin" at Dec 16, 97 05:42:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Igor Timkin uttered: > Unfortunally, I still have this problem. > I had make newfs 5 days ago. But yestarday I got the same panic > (uptime 5.2 days): 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. Unfortunately the crash dumps from subsequent panics were the result of trying to delete an older file that had one of it's blocks hijacked in this way, so I haven't been able to gather any more data about it. Could you check the list of direct blocks in the dinode part of the in-core inode struct and see if there's corruption I'd be grateful. steve -- // stephen clawson sclawson@cs.utah.edu // university of utah