Messages in this thread | | | Date | Wed, 11 Oct 2006 16:22:05 +0200 | From | Jan Kara <> | Subject | Re: 2.6.18 ext3 panic. |
| |
> Jan Kara wrote: > > > Umm, but these two traces confuse me: > >1) They are different traces that those you wrote about initially, > >aren't they? Because here we would not call sync_dirty_buffer() from > >journal_dirty_data(). > > BTW: Does this buffer trace lead to that Oops in submit_bh()? I guess not > >as the buffer is not dirty... > > They do wind up at the same oops, from the same "testcase" (i.e. beat the > tar out of the filesystem with multiple fsx's and fsstress...) > > The buffer is not dirty at that tracepoint because it has just done > if (locked && test_clear_buffer_dirty(bh)) { > prior to the tracepoint... Oh, I see. OK.
> > See the whole traces at > > http://people.redhat.com/esandeen/traces/eric_ext3_oops1.txt > http://people.redhat.com/esandeen/traces/eric_ext3_oops2.txt Hmm, those traces look really useful. I just have to digest them ;).
> As an aside, when we do journal_unmap_buffer... should it stay on > t_sync_datalist? Yes, it should and it seems it really was removed from it at some point. Only later journal_dirty_data() came and filed it back to the BJ_SyncData list. And the buffer remained unmapped till the commit time and then *bang*... It may even be a race in ext3 itself that it called journal_dirty_data() on an unmapped buffer but I have to read some more code.
Bye Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |