From: Jean-Pierre Dion <jean-pierre.dion@bull.net>
To: jrs@us.ibm.com
Cc: linux-ext4@vger.kernel.org
Subject: Re: Ext4 benchmarks
Date: Wed, 28 Mar 2007 11:06:24 +0200 [thread overview]
Message-ID: <460A3010.6080201@bull.net> (raw)
In-Reply-To: <4600A1BD.80700@us.ibm.com>
Hi Jose,
thank you for the feedback.
We took your remarks into account and we are doing some perfs with
iozone (close to desktop activity, mono-thread) and ffsb (allows to run
benchs
in a multi-thread activity like a server does, different blocks sizes...).
We compare ext3 and ext4 (with extents, w/ and w/o del alloc...)...
We will publish the results on bullopensource.org
jean-pierre
Jose R. Santos wrote:
> Jean-Pierre Dion wrote:
>> Hi all,
>>
>> we already discussed during the conf calls what
>> benchmarks should be ran on ext4.
>>
>> As we have OLS paper on the table we were thinking
>> here at Bull what bench t run and on which kernel.
>>
>> If we want trying to compare ext3 and ext4, I guess we
>> should at least show that :
>> - ext4 has equivalent perfs than ext3,
>>
>
> Define equivalent performance.
>
> Are the workloads only going to be focused on single repetitive
> operations or simulation of actual desktop/server environments? How
> about performance on an aged filesystem?
>> - improvements done for ext3 are still in ext4 (mb alloc, del alloc...).
>>
>> So we were wondering what's best to do :
>> - run on 2.6.19 (includes del alloc and mb alloc if I am not wrong),
>> - run on 2.6.20 (lacks mb alloc),
>>
>
> What about system configurations? While a desktop configuration would
> be easy to come by, a server configuration needs a bit more thought.
> Will ext4 perform better than ext3 in a wide range of storage
> configuration that scale from a couple thousands IOPS to several
> hundred thousand IOPS?
>
> Having baseline data on other filesystems like XFS or JFS would be
> interesting as well to see how well ext4 stacks up to the competition. :)
>> - select relevant benchs (iozone...).
>>
>
> I haven checked IOzone in quite a bit but last time I checked FFSB had
> a couple of capabilities that are not available in IOzone like multi
> threading on a shared data set and a very customizable IO operations
> to attempt to simulate real IO patterns seen on workloads. Might be
> worth a look if your interested in compiling a very comprehensive set
> of results
>> What do you think ?
>>
>> Thanks.
>>
>>
>> jean-pierre
>>
>
> -JRS
>
next prev parent reply other threads:[~2007-03-28 9:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-20 15:20 Ext4 benchmarks Jean-Pierre Dion
2007-03-21 3:08 ` Jose R. Santos
2007-03-28 9:06 ` Jean-Pierre Dion [this message]
2007-03-28 11:27 ` Ric Wheeler
2007-04-02 14:55 ` Jean-Pierre Dion
2007-03-28 14:20 ` Jose R. Santos
2007-03-30 8:43 ` Johann Lombardi
2007-03-30 18:50 ` Andreas Dilger
2007-04-02 14:56 ` Jean-Pierre Dion
2007-04-04 17:06 ` Cordenner jean noel
2007-04-04 19:21 ` Andreas Dilger
2007-04-04 21:18 ` Mingming Cao
2007-04-04 22:40 ` ext4 patch queue update Mingming Cao
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=460A3010.6080201@bull.net \
--to=jean-pierre.dion@bull.net \
--cc=jrs@us.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.