From: Steven Pratt <slpratt@austin.ibm.com>
To: Yan Zheng <yanzheng@21cn.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Random write regression
Date: Tue, 21 Jul 2009 09:48:38 -0500 [thread overview]
Message-ID: <4A65D546.9000602@austin.ibm.com> (raw)
In-Reply-To: <3d0408630907210004g34a49196xb235aa2f6a1f0f1b@mail.gmail.com>
Yan Zheng wrote:
> 2009/7/20 Steven Pratt <slpratt@austin.ibm.com>:
>
>> Finally got around to going through latest data. Seems like we lost all the
>> random write performance gains. Creates are better, but total regression on
>> the random workload. Sequential reads seem to have dropped as well.
>>
>> Results are uploading now.
>> http://btrfs.boxacle.net/repository/raid/history/History.html
>>
>> These are for RAID only as single disk system still having issues completing
>> btrfs runs. Also, missing oprofile duw to oprofile causing an NMI and
>> killing the system.
>>
>> Chris, this was built on 7/6, but I see no new changes sine 7/2/.
>> Steve
>>
>>
>>
>
> The output of ffsb in the latest 128 threads random odirect write benchmark was
> ....
> checking existing fs: /mnt/ffsb1
> fs setup took 6 secs
> Syncing()...2 sec
> ....
>
> The corresponding output on 30 June was
> ....
> creating new fileset /mnt/ffsb1
> fs setup took 847 secs
> Syncing()...1 sec
> ....
>
> It seems the filesystem used in the latest benchmark wasn't freshly created.
>
Yes, the older (better) random write performance did indeed recreate the
files before the test. Thanks for catching this. I had 2 job files, 1
for just btrfs and 1 for all file systems and the reuse flag is
different between them. Please ignore this regression. I will re-run
without the reuse flag and expect things to be similar. This does
indicate that btrfs degrades quite rapidly under random write, but that
is a separate topic.
Steve
> Yan, Zheng
>
prev parent reply other threads:[~2009-07-21 14:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-20 13:11 Random write regression Steven Pratt
2009-07-20 13:34 ` Chris Mason
2009-07-20 14:47 ` Steven Pratt
2009-07-21 7:04 ` Yan Zheng
2009-07-21 14:48 ` Steven Pratt [this message]
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=4A65D546.9000602@austin.ibm.com \
--to=slpratt@austin.ibm.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=yanzheng@21cn.com \
/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.