reproduced: ffs_blkfree: freeing free block
Don Lewis
truckman at FreeBSD.org
Sat Jan 15 15:30:00 PST 2005
On 15 Jan, Poul-Henning Kamp wrote:
>
> Quite by accident my test-machine here can now reliably reproduce
> the dreaded "panic: ffs_blkfree: freeing free block" in a few minutes
> of time.
>
> It is very interesting that the location of the actual error is a
> very narrow stripe of the filesystem:
>
> dev = ad8, block = 13456368, fs = /hex
> dev = ad8, block = 13455888, fs = /hex
> dev = ad8, block = 13454688, fs = /hex
> dev = ad8, block = 13455040, fs = /hex
> dev = ad8, block = 13455200, fs = /hex
> dev = ad8, block = 13455880, fs = /hex
>
> The application I'm running at the time adds/modifies records in a
> db(3) hash file and nothing much besides.
>
> Before I start implementing complete I/O traces and spend days
> groveling over UFS/FFS on-disk bits, are there anybody who has
> suggestions for things I should try to enable/disable to narrow
> this down ?
I'm reasonably certain that the on-disk bits are ok. I'm seeing it in
the case where a freshly written file is being re-written. If I unmount
the file system after the file is initially created, the file system
fsck's clean, and if I then remount the file system, I am unable to
reproduce the problem. Fsdb lists the block causing the panic as one
that was initially allocated to the file. It looks like the in-core
block bitmap is getting corrupted.
In my openoffice build example, the following final step is sufficient
to trigger the panic:
jot -b x 174113 > \
/mnt/usr/ports/editors/openoffice-1.1/work/config_office/configure
Merely truncating the file with "cat /dev/null" does not appear to be
sufficient to trigger the panic.
More information about the freebsd-current
mailing list