Re: reproduced: ffs_blkfree: freeing free block

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.