linux-ext4 - Re: Revert Fix-EXT_MAX

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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)