Re: 2.5.18 / ext3 / oracle trouble

[Andrew Morton <akpm@zip.com.au>]

Zlatko Calusic wrote:
> 
> Zlatko Calusic <zlatko.calusic@iskon.hr> writes:
> >
> > Obviously I need to perform tests on ext2 with swap load, and repeat
> > them few times. Will do this evening (it takes some time to recover a
> > database after a corruption, so it's slightly time consuming).
> >
> 
> And I did get some interesting results. :)
> I found a great test case, rebuilding database after corruption. :)
> 
> It consists of recreation of all tablespaces, initializing data
> dictionary and finally importing useful data. The whole process takes
> between 11 and 14 minutes, depending on the type of FS. It's write
> intensive workload and induces some paging even with 768 MB RAM I
> have. Did I forgot to say that all this is on a SMP machine, dual
> PIII? It might matter.
> 
> And you know what, corruption doesn't depend on the type of FS. It
> happens on both ext2 & ext3. It's just more likely to see it when
> running on ext3.
> 
> Anyway, I managed to pinpoint the problem, it's paging that's the
> culprit. When I turned off my swap partition (swapoff -a), rebuild
> went correctly. So I was right, swapping will get you in
> trouble.

Thanks.  I'll cook up a test for that.

> I also tried to push the machine harder into swap, with artificial
> load (typical malloc() in the loop), and it locked up hard after some
> time (minute or two).
> 
> And during one of the tests on ext3, when machine actually survived,
> just after exiting X I had a welcome message waiting, saying something
> like this:
> 
>  Assertion failure: journal_dirty_metadata() at transaction.c:1146
>  "jh->b_frozen_data == 0"

I've seen them under load with data=journal.  Were you using data=journal
at the time?

-