From: Theodore Tso <tytso@mit.edu>
To: Holger Kiehl <Holger.Kiehl@dwd.de>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Girish Shilamkar <Girish.Shilamkar@sun.com>,
linux-ext4@vger.kernel.org
Subject: Re: Revert Fix-EXT_MAX_BLOCK.patch
Date: Fri, 11 Jul 2008 08:43:04 -0400 [thread overview]
Message-ID: <20080711124304.GB8154@mit.edu> (raw)
In-Reply-To: <Pine.LNX.4.64.0807110947290.31436@diagnostix.dwd.de>
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
next prev parent reply other threads:[~2008-07-11 12:43 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 8:02 Performance of ext4 Holger Kiehl
2008-06-11 10:59 ` Aneesh Kumar K.V
2008-06-11 19:58 ` Holger Kiehl
2008-06-11 20:17 ` Nick Dokos
2008-06-12 9:02 ` Holger Kiehl
2008-06-12 10:58 ` Solofo.Ramangalahy
2008-06-12 12:00 ` Holger Kiehl
2008-06-12 13:19 ` Theodore Tso
2008-06-12 14:07 ` Holger Kiehl
2008-06-12 18:06 ` Aneesh Kumar K.V
2008-06-12 19:50 ` Holger Kiehl
2008-06-13 8:05 ` Holger Kiehl
2008-06-16 17:54 ` Jan Kara
2008-06-16 18:13 ` Aneesh Kumar K.V
2008-06-17 11:42 ` Holger Kiehl
2008-06-18 5:58 ` Holger Kiehl
2008-06-19 6:58 ` Andreas Dilger
2008-06-19 11:09 ` Theodore Tso
2008-06-19 15:04 ` Holger Kiehl
2008-07-07 13:13 ` Holger Kiehl
2008-07-10 8:11 ` Holger Kiehl
2008-07-10 9:24 ` Aneesh Kumar K.V
2008-07-10 9:26 ` Revert Fix-EXT_MAX_BLOCK.patch Aneesh Kumar K.V
2008-07-10 12:22 ` Theodore Tso
2008-07-10 12:38 ` Aneesh Kumar K.V
2008-07-10 13:02 ` Theodore Tso
2008-07-10 12:24 ` Theodore Tso
2008-07-11 9:57 ` Holger Kiehl
2008-07-11 12:43 ` Theodore Tso [this message]
2008-07-11 14:57 ` Holger Kiehl
2008-07-14 19:55 ` Holger Kiehl
2008-07-14 20:28 ` Theodore Tso
2008-07-15 6:43 ` Holger Kiehl
2008-06-19 15:56 ` Performance of ext4 Theodore Tso
2008-06-19 16:41 ` Eric Sandeen
2008-06-19 16:41 ` Eric Sandeen
2008-06-19 17:42 ` Theodore Tso
2008-06-19 19:51 ` Mingming
2008-06-20 8:32 ` Holger Kiehl
2008-06-20 8:59 ` Theodore Tso
2008-06-20 9:21 ` Holger Kiehl
2008-06-23 17:45 ` Aneesh Kumar K.V
2008-06-24 0:31 ` Mingming
2008-06-24 0:31 ` Mingming
2008-06-24 3:07 ` Aneesh Kumar K.V
2008-06-24 3:28 ` Aneesh Kumar K.V
2008-06-24 3:33 ` Aneesh Kumar K.V
2008-06-24 21:12 ` Holger Kiehl
2008-06-24 22:58 ` Mingming
2008-06-25 9:09 ` Holger Kiehl
2008-06-26 0:46 ` Mingming
2008-06-27 9:14 ` Aneesh Kumar K.V
2008-06-27 9:14 ` Aneesh Kumar K.V
2008-06-27 9:49 ` Aneesh Kumar K.V
2008-06-27 10:00 ` Jan Kara
2008-06-27 17:35 ` Aneesh Kumar K.V
2008-06-24 17:58 ` Mingming
2008-06-24 12:57 ` Holger Kiehl
2008-06-23 20:55 ` Andreas Dilger
2008-06-20 8:09 ` Holger Kiehl
2008-06-21 15:02 ` Holger Kiehl
2008-06-11 13:54 ` Theodore Tso
2008-06-11 20:21 ` Holger Kiehl
2008-06-12 1:35 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080711124304.GB8154@mit.edu \
--to=tytso@mit.edu \
--cc=Girish.Shilamkar@sun.com \
--cc=Holger.Kiehl@dwd.de \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.