Andrew Morton wrote:
On Wed, 6 Sep 2006 19:27:33 +0200
Jan Kara <[email protected]> wrote:
Ugh! Are you sure? For this path the buffer must be attached (only) to
the running transaction. But then how the commit code comes to it?
Somebody would have to even manage to refile the buffer from the
committing transaction to the running one while the buffer is in wbuf[].
Could you check whether someone does __journal_refile_buffer() on your
marked buffers, please? Or whether we move buffer to BJ_Locked list in
the write_out_data: loop? Thanks.
The ext3-debug patch will help here. It records, within the bh, the inputs
from the last 32 BUFFER_TRACE()s which were run against this bh. If a
J_ASSERT fails then you get a nice trace of the last 32 "things" which
happened to this bh, including the bh's state at that transition. It
basically tells you everything you need to know to find the bug.
It's worth spending the time to become familiar with it - I used it a lot in
early ext3 development.
I will try the patch. Unfortunately, adding more debug is causing the
problem reproduction
difficult.
I've been unable to reproduce this crash, btw. Is there some magic
incantation apat from running `fsx-linux'?
All I do is on a single 1k filesystem, run 4 copies of fsx (on 4
different files, ofcourse).
I hit the assert anywhere between 10min-2hours.
Thanks,
Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
