[Top] [All Lists]

Re: Oops removing files on a full f/s

To: "'XFS Mailing List'" <linux-xfs@xxxxxxxxxxx>
Subject: Re: Oops removing files on a full f/s
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Tue, 19 Jun 2001 23:36:31 +1000
References: <015801c0f85d$2cdde340$0a01a8c0@den2>
Sender: owner-linux-xfs@xxxxxxxxxxx
Juha Saarinen wrote:
> fsstress filled up /usr 100% so I was going remove the p* directories
> and files. This provoked an oops:
> Kernel BUG at ll_rw_blk.c:700!

Ah. ll_rw_blk.c:700.  I know it well.

My bet: A buffer was unmapped in block_flushpage() but somehow
somebody set it dirty again, and bdflush/kupdate tried to write
the thing out.

For ext3 I have implemented a "buffer tracing" mechanism.  At
any interesting pointin the lifecycle of a buffer_head you

        BUFFER_TRACE(bh, "some descriptive text")

then, thoughout the code I've added things like:

        J_ASSERT_BH(bh, some_expression);

If the assertion fails you get a 64-slot backtrace of
all the buffer's state transitions.  There's an example
output trace from when I was hitting exactly this same BUG()
at http://www.zip.com.au/~akpm/buffer-trace.txt - it's great.
See how journal_commit_transaction incorrectly sets the
buffer dirty and then flush_dirty_buffers grabs it.

I guess it's a bit late in XFS's development cycle to incorporate
something like this though.

<Prev in Thread] Current Thread [Next in Thread>