On Fri, 11 Jul 2008, Theodore Tso wrote:
On Fri, Jul 11, 2008 at 09:57:47AM +0000, Holger Kiehl wrote:Thanks. Reverting that patch also fixed it for me. I was able to do my test however performance is down another 10% (compared to ext4-patch-queue-52c8a02a8a7b7e5915b9301e9c171b4faf22b928). ext4 is getting slower and slower :(How reproducible are your results? That is, if you run the benchmarks multiple times, how much variance is there between different runs? If you are willing, this would be helpful. In your ext4 patch repository, try out commit 179a876b. (You can do this via "git checkout -b rc9-rebase 179a876b"; after doing the test you can switch the working directory of the ext4 patch queue back to the master branch via "git checkout master".) This commit is pretty much identical to your previous 52c8a02a test, modulo rebasing to -rc9. If you see the same results, you could try going to the next patch, via "git checkout -b i-blocks-stat ef019f0a" which also has the fix so that stat returns a valid i_blocks field for files that have been freshly written when delayed allocation is enabled. Both of these revisions rae before the patches that were causing corrupion were added to the patch queue, so it should be fine. The funny thing is looking at the various recent patches, I don't see how they could be affecting performance of your patches so significantly. I gather afdbench is very metadata intensive, with lots of small files, but even so, none of these patches should make that kind of difference. So that's why I'm wondering how much variance there is between runs of afdbench, and whether that might be a possible explanation.
You are right. I did compare the .config of both and noticed that CONFIG_FAIR_GROUP_SCHED was set in the rc9 test but not in rc8 test. Doing the test without CONFIG_FAIR_GROUP_SCHED gave me back 6%. Sorry.
Also the group descriptors still get corrupted.Hmm, can you send me the output of dumpe2fs before and after the benchmark run which corrupts the group descriptors? And can you send me the output of "e2fsck -fy /dev/XXXXX >& /tmp/log", so I can see what got corrupted?
I did several test runs with dumpe2fs before and after, but it would then not cause any corruption. Leaving it away I got the corruption. So attached you will find dumpe2fs after corruption in unmounted state and the e2fsck output. Is this of any use? Holger
Attachment:
dumpe2fs.after4.bz2
Description: BZip2 compressed data
Attachment:
e2fsck.log4.bz2
Description: BZip2 compressed data
