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 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.