lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Pine.LNX.4.64.0807141938250.28835@diagnostix.dwd.de> Date: Mon, 14 Jul 2008 19:55:10 +0000 (GMT) From: Holger Kiehl <Holger.Kiehl@....de> To: Theodore Tso <tytso@....edu> Cc: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>, Girish Shilamkar <Girish.Shilamkar@....com>, linux-ext4@...r.kernel.org Subject: Re: Revert Fix-EXT_MAX_BLOCK.patch 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 Download attachment "dumpe2fs.after4.bz2" of type "APPLICATION/x-bzip2" (50897 bytes) Download attachment "e2fsck.log4.bz2" of type "APPLICATION/x-bzip2" (959 bytes)
Powered by blists - more mailing lists