Re: ffs_blkfree: freeing free block -- ps, traces, fsck log

On  2 May, Robert Watson wrote:
> 
> I updated a pxe box to a recent -current, and applied it to a UFS
> partition I had on disk.  I ran several parallel tars, an rm -Rf on one of
> the tar extract targets, and a dd if=/dev/zero of=tmp on the partition,
> and within a few minutes reproduced the nefarious ffs_blkfree() panic. 
> Some debugging information as follows; I included stack traces of some of
> the more interesting threads.  I've also included the fsck output below --
> the background file system checker was not active at the time as it's
> manually mounted and fscked when used; I believe the file system has never
> actually had the background file system checker used on it, certainly not
> with a recent kernel.  The output from fsck -y on the partition is also
> attached.  As you can see, there are some alarming "ALLOCATED FRAG xxx
> MARKED FREE" messages.

Have you tried to see if the DEBUG_VFS_LOCKS kernel configuration option
catches any vnode locking problems?  I'm using this option and so far I
have not been able to trigger the bug.

I see that you're running NFS, though it appears to be idle at the time
of the crash.  I tried the NFS server code for the first time the other
day with the DEBUG_VFS_LOCKS option and immediately ran into some
locking bugs. The client code is in pretty good shape.