Re: 2.5.18 / ext3 / oracle trouble

[Zlatko Calusic <zlatko.calusic@iskon.hr>]

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.

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"

Don't know if it's related, but could be useful to someone.

That's it. I'm back to 2.4.19-pre8 for the time being, but if anybody
needs more testing...

Regards,
-- 
Zlatko