From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Eric Whitney's ext4 scaling data
Date: Wed, 27 Mar 2013 11:33:23 +0800 [thread overview]
Message-ID: <20130327033322.GB9887@gmail.com> (raw)
In-Reply-To: <nsxhajyzu6n.fsf@closure.thunk.org>
On Tue, Mar 26, 2013 at 12:00:48AM -0400, Theodore Ts'o wrote:
>
> Eric Whitney has very thoughtfully provided an updated set of ext4
> scalability data (with comparisons against ext3, xfs, and btrfs)
> comparing performance between 3.1 and 3.2, and comparing performance
> between 3.2 and 3.6-rc3.
>
> I've made his compressed tar file available at:
>
> https://www.kernel.org/pub/linux/kernel/people/tytso/ext4_scaling_data.tar.xz
> https://www.kernel.org/pub/linux/kernel/people/tytso/ext4_scaling_data.tar.gz
>
> His comments on this data are:
>
> It contains two sets of data - one comparing 3.2 and 3.1 (this was
> the last data set I posted publicly) and another comparing 3.6-rc3
> and 3.2. 3.6-rc3 was the last data set I collected, and until now, I
> hadn't prepared graphs for it. The graphical results are consistent
> with what I'd reported verbally over the first 2/3 of last year - not
> much change between 3.2 and 3.6-rc3. The last large change I could
> see occurred in 3.2, as mentioned in the notes.
>
> The tarball unpacks into a directory named ext4_scaling_data and
> contains a few subdirectories. The directories named 3.2 and 3.6-rc3
> map to the data sets described above. Each contains a file named
> index.html which you can open with a web browser to see the graphs,
> browse the raw data, ffsb profiles and lockstats, etc.
>
> Hopefully you'll find the lockstats and other information useful,
> even though stale (3.6-rc3 became available the last week in August
> 2012).
>
> Thanks, Eric for making this data available!
Thanks for sharing this with us. I have an rough idea that we can create
a project, which have some test cases to test the performance of file
system. We can use fio to simulate all kinds of scenarios, such as
- logger app (buffered io, append write, sequential write);
- distribute file system (preallocate, buffered io, random read/write)
- database (direct io, random read/write)
- search (mmapped, random read, periodic append write)
- ...
If we want to measure the performance of file system, we could simply
run a script to run some cases and get some result.
Currently we already have xfstests, but AFAIK it can verify that there
is no bug, deadlock, etc. in a file system, and it couldn't tell us
whether there has a performance regression after applied some patches.
(Please correct me if I am wrong.) So the question is whether it is
worth creating a new project. Or we should add these test cases into
xfstests.
Regards,
- Zheng
next prev parent reply other threads:[~2013-03-27 3:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 4:00 Eric Whitney's ext4 scaling data Theodore Ts'o
[not found] ` <alpine.LFD.2.00.1303261555140.2455@(none)>
2013-03-27 3:29 ` Theodore Ts'o
2013-03-27 3:33 ` Zheng Liu [this message]
2013-03-27 3:35 ` Theodore Ts'o
2013-03-27 7:21 ` Zheng Liu
2013-03-27 15:10 ` Theodore Ts'o
2013-03-28 4:49 ` Zheng Liu
2013-03-28 5:14 ` Dave Chinner
2013-04-01 3:43 ` Eric Whitney
2013-03-28 5:07 ` Dave Chinner
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=20130327033322.GB9887@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).