From: cwillu <cwillu@cwillu.com>
To: Marek Fstump <marekfstump@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: very poor read / write performance compared to other FS's?
Date: Wed, 11 May 2011 16:41:10 -0600 [thread overview]
Message-ID: <BANLkTinBsvfa1ZbOVMoP=Mm_h-_it8Ps-Q@mail.gmail.com> (raw)
In-Reply-To: <BANLkTinRa9TdVOAaMt9_gcR2xDhbDWVJcA@mail.gmail.com>
On Wed, May 11, 2011 at 4:33 PM, Marek Fstump <marekfstump@gmail.com> w=
rote:
> Hi
>
> I am very interested in using BTRFS for my solution but in basic test=
s
> it seems to be very poor on read and write performance. =C2=A0I am
> surprised by this so suspect that maybe I am doing something
> incorrectly or that there are updates I should be using, but I am not
> sure how I update BTRFS on SLES11
>
> Summary:
> RESULTS on link below
> SLES11 SP1
> Compared Sequential read/write performance against XFS and OCFS2
> Backend storage =E2=80=93 FusionIO SLC SSD =3D circa 750MBsec
>
> Tests =C2=A0set as follows:
> Filesystem contains 30 x 4GB files (made of random data)
> Read tests will read from 1 to 30 files concurrently
> Write tests will write 1 to 30 concurrent NEW files (simple 000=E2=80=
=99s)
> dd -direct flag used on writes
>
> All defaults used for mounting etc.
>
> Results shown in attachment.
>
> BTRFS looks an excellent FS and perfect for my application and I am
> hoping that there are some factors that I am missing
> and would appreciate any advice / help
>
> Graph is here (Thank you =E2=80=98cwillu=E2=80=99)
>
> http://cwillu.com/files/btrfs/read-write_perf.pdf
A couple questions:
Which kernel version?
How big is the partition the testing is done on?
How does btrfs compare if you drop the -direct flag, and instead sync
+ drop_caches before, and time until sync completes after dd (for all
of them, not just btrfs)?
There are a couple btrfs mount options that will improve performance
in this particular case, but this benchmark may not reflect your
actual needs.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-11 22:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 22:33 very poor read / write performance compared to other FS's? Marek Fstump
2011-05-11 22:41 ` cwillu [this message]
2011-05-26 12:57 ` Marek Fstump
2011-05-12 15:39 ` Josef Bacik
2011-05-12 23:15 ` Marek Fstump
2011-05-13 2:07 ` Daniel J Blueman
2011-05-12 23:34 ` Mark Fasheh
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='BANLkTinBsvfa1ZbOVMoP=Mm_h-_it8Ps-Q@mail.gmail.com' \
--to=cwillu@cwillu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=marekfstump@gmail.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 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).