very poor read / write performance compared to other FS's?

very poor read / write performance compared to other FS's?

[Marek Fstump]

Hi

I am very interested in using BTRFS for my solution but in basic tests
it seems to be very poor on read and write performance.  I 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 =96 FusionIO SLC SSD =3D circa 750MBsec

Tests  set as follows:
=46ilesystem 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=92s)
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 =91cwillu=92)

http://cwillu.com/files/btrfs/read-write_perf.pdf

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

Re: very poor read / write performance compared to other FS's?

[cwillu]

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

Re: very poor read / write performance compared to other FS's?

[Josef Bacik]

On Wed, May 11, 2011 at 11:33:35PM +0100, Marek Fstump wrote:
> Hi
>=20
> 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.  I 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
>=20
> 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
>=20
> Tests  set 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
>=20
> All defaults used for mounting etc.
>=20
> Results shown in attachment.
>=20
> 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
>=20

Yeah our O_DIRECT performance is less than stellar, I just did a bunch =
of work
to try and help us get a little better performance.  Would you mind pul=
ling
down linus's git tree and testing on that and seeing if you get better
performance?  Thanks,

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

Re: very poor read / write performance compared to other FS's?

[Marek Fstump]

On Thu, May 12, 2011 at 4:39 PM, Josef Bacik <josef@redhat.com> wrote:
> On Wed, May 11, 2011 at 11:33:35PM +0100, Marek Fstump wrote:
>> Hi
>>
>> I am very interested in using BTRFS for my solution but in basic tes=
ts
>> it seems to be very poor on read and write performance. =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 no=
t
>> 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 =96 FusionIO SLC SSD =3D circa 750MBsec
>>
>> Tests =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=92s)
>> 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
>>
>
> Yeah our O_DIRECT performance is less than stellar, I just did a bunc=
h of work
> to try and help us get a little better performance. =A0Would you mind=
 pulling
> down linus's git tree and testing on that and seeing if you get bette=
r
> performance? =A0Thanks,
>
> Josef
>

Hi Josef

=46orgive me as i am a 'storage guy' - so when you say pull down linus'=
s
git tree and test.... do you mean grab the latest kernel?  i know very
stupid question, but just want to make sure i get it right... if so,
then yes i will and i will add some more storage power also to see if
it scales.



THank you
--
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

Re: very poor read / write performance compared to other FS's?

[Mark Fasheh]

On Wed, May 11, 2011 at 11:33:35PM +0100, Marek Fstump wrote:
> I am very interested in using BTRFS for my solution but in basic tests
> it seems to be very poor on read and write performance.  I 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

Hey Marek, just fyi that the btrfs version in sles11 sp1 is old (by btrfs
standards :). That's not surprising of course as btrfs isn't supported yet
in any enterprise distributions. My guess is that you should see better
results with a more recent kernel.
	--Mark

--
Mark Fasheh

Re: very poor read / write performance compared to other FS's?

[Daniel J Blueman]

On 13 May 2011 07:15, Marek Fstump <marekfstump@gmail.com> wrote:
> On Thu, May 12, 2011 at 4:39 PM, Josef Bacik <josef@redhat.com> wrote=
:
>> On Wed, May 11, 2011 at 11:33:35PM +0100, Marek Fstump wrote:
>>> Hi
>>>
>>> I am very interested in using BTRFS for my solution but in basic te=
sts
>>> it seems to be very poor on read and write performance. =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 n=
ot
>>> 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 =96 FusionIO SLC SSD =3D circa 750MBsec
>>>
>>> Tests =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=92s=
)
>>> 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
>>>
>>
>> Yeah our O_DIRECT performance is less than stellar, I just did a bun=
ch of work
>> to try and help us get a little better performance. =A0Would you min=
d pulling
>> down linus's git tree and testing on that and seeing if you get bett=
er
>> performance? =A0Thanks,
>>
>> Josef
>>
>
> Hi Josef
>
> Forgive me as i am a 'storage guy' - so when you say pull down linus'=
s
> git tree and test.... do you mean grab the latest kernel? =A0i know v=
ery
> stupid question, but just want to make sure i get it right... if so,
> then yes i will and i will add some more storage power also to see if
> it scales.

=46or  SLES 11, the kernel RPMs here may be your best shot:

http://download.opensuse.org/repositories/Kernel:/stable/standard/x86_6=
4/

(eg kernel-default-2.6.38.6-1.1.x86_64.rpm)

You'll probably have to download dependent RPMs from there too.

Thanks,
  Daniel
--=20
Daniel J Blueman
--
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

Re: very poor read / write performance compared to other FS's?

[Marek Fstump]

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

Hi,

Following up on this thread i download the latest OpenSUSE and
repeated the read / write performamce test and again compared to XFS
etc.

Reads seem good.  But writes are still way down compared to XFS.

Also BTRFS seems to scale in performance very purely?  whilst all the
FS's i tested ramp up performance within a couple of DDs or threads...
btrfs just doesnt, so for most typical writes while XFS is around
1300MBsec , btrfs is only around 500MBsec


Any ideas?


Marek


On Thu, May 12, 2011 at 12:41 AM, cwillu <cwillu@cwillu.com> wrote:
> On Wed, May 11, 2011 at 4:33 PM, Marek Fstump <marekfstump@gmail.com> wrote:
>> Hi
>>
>> I am very interested in using BTRFS for my solution but in basic tests
>> it seems to be very poor on read and write performance.  I 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 – FusionIO SLC SSD = circa 750MBsec
>>
>> Tests  set 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’s)
>> 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 ‘cwillu’)
>>
>> 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.
>

[-- Attachment #2: Capture.PNG --]
[-- Type: image/png, Size: 52373 bytes --]