Re: panic: bundirty: buffer 0xc776e118 still on queue 2

From: Tim Robbins <tjr_at_FreeBSD.ORG>
Date: Thu, 21 Aug 2003 21:18:29 +1000
On Thu, Aug 21, 2003 at 10:26:08AM +0200, Christian Brueffer wrote:

> On Thu, Aug 21, 2003 at 05:57:28PM +1000, Tim Robbins wrote:

> > Did one of the servers go down shortly before the panic, then? The last few
> > lines of dmesg might be useful.
> > 
> 
> No indication for that in the logs.  I would have noticed anyway, as I was
> playing music from one of the shares.
> One of the shared file systems was full (besides the reserved space) at the
> time of the panic.  Could that have to do something with it?

Perhaps. On closer examination, the backtrace doesn't match exactly the
problem I'd seen and worked around in NTFS, but it seems to be related to it.
Bad things happen when the cache can't write a dirty buffer back to disk --
in the NTFS case, this was triggered by another buffer cache bug that
caused it to try to write a non-dirty buffer back to a read-only disk[*].
I would have thought that disk space on the server would have already been
allocated for the buffer, so I'm not sure whether the filesystem being full
could have caused a write error.

But in any case, I'm not sure how to fix the bug you encountered,
even if my speculations turn out to be correct. At one stage I thought
I had found a logic error in brelse()'s handling of write errors, but
I don't remember the specifics anymore.


Tim


[*] vfs_bio.c:getblk():gbincore(...) != NULL && bp->b_bcount != size &&
!(bp->b_flags & B_VMIO) && !(bp->b_flags & B_DELWRI) -> write
non-dirty buffer to disk.
Received on Thu Aug 21 2003 - 02:18:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:19 UTC