Date: Tue, 16 Dec 1997 22:13:01 -0700 (MST) From: sclawson@bottles.cs.utah.edu (steve clawson) To: ivt@gamma.ru (Igor Timkin) Cc: tlambert@primenet.com, ivt@gamma.ru, freebsd-hackers@FreeBSD.ORG Subject: Re: panic: blkfree: freeling free block/frag Message-ID: <199712170513.WAA03545@bottles.cs.utah.edu> In-Reply-To: <199712161442.RAA24936@crocus.gamma.ru> from "Igor Timkin" at Dec 16, 97 05:42:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712170513.WAA03545>