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]

Message-ID: <20080711124304.GB8154@mit.edu>
Date:	Fri, 11 Jul 2008 08:43:04 -0400
From:	Theodore Tso <tytso@....edu>
To:	Holger Kiehl <Holger.Kiehl@....de>
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, 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.

> 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 also note that you are using a fairly old e2fsprogs from April 27th.
You might want to try going to the just-released e2fsprogs 1.41.0
released yesterday, as that has some flex_bg layout changes that might
help out performance for afdbench.  Also note that with both the April
27th and the latest e2fsprogs 1.41.0 release, there is a mke2fs.conf
file in misc/mke2fs.conf that should be installed in /etc/mke2fs.conf
for best results.

> PS: http://repo.or.cz/w/ext4-patch-queue.git is empty, is that correct?

Nope, we're working on that.  Things seem to have gotten corrupted on
repo.or.cz, as you may have seen on another e-mail thread.  I have
established an git repository here:

	    git://git.kernel.org/pub/scm/fs/ext2/ext4-patch-queue.git

As an interim replacement.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html