Where The Btrfs Performance Is At Today

[phoronix]

Phoronix: Where The Btrfs Performance Is At Today

With MeeGo using Btrfs by default, Canonical making plans for Btrfs in as soon as Ubuntu 10.10, and Novell now pushing Btrfs in openSUSE, among other milestones for this advanced Linux file-system, we decided to see where the Btrfs performance is now at with the Linux 2.6.35 kernel that's currently in development. We compare the Btrfs performance to EXT4 and see how some of the different mount options are affecting the file-system's performance in different benchmarks.

http://www.phoronix.com/vr.php?view=15004

[thefirstm]

Maybe you should also make a benchmark that shows how much more CPU is used when compressing.

[ttxdragon]

With the Flexible IO Tester, Btrfs was faster than EXT4 with each using their default mount options by a difference of 31%. This lead expanded to 64% with the compression support.

Maybe I'm missing something, but the graph shows the opposite?

[kernelOfTruth]

Maybe I'm missing something, but the graph shows the opposite?

this.

in the graphics it's also explained that "fewer are better"


Thanks for the tests !

btw: Michael could you please make some tests in the future with noatime, relatime enabled ?

afaik in some distribution relatime should be the default

few people (regular users) should need access time updates & this also might help to speed up filesystem (write) performance to some degree

[V!NCENT]

The btrfs wiki is outdated, just like Wikipedia english.

EXT4 should be the mixed-gap between the old and the new. So how far away is btrfs from replacing EXT4?

[paravoid]

Interesting results. Indeed I also suspect some performance impact on btrfs compress mode at least.
Also, I would be curious about the outcome with at least two additional kernel versions: stable vanilla (2.6.34) and development (2.6.35-rc2 or better current git head).

Thanks!

[mutlu_inek]

I would love some file system tests which include a) cpu usage and b) LUKS encryption.

[iq-0]

I like the quick comprehensive overview of the article. A few things which are interesting would be: CPU usage, Disk utilisation (iostat -x) to give some reference as to where the bottlenecks are and if big improvements are to be expected.
And perhaps most interesting to 'nocow' without the 'compress' because I suspect that compress has an averse effect when not using COW semantics (because the newly written data after compression may be larger or smaller than the old data leading requiring possibly complex workarounds).

But otherwise a nice quick "where are we now" update.


(And the Flexible IO Tester conclusion doesn't match the graph's description, but others already reported that)

[devius]

So it's probably a good idea to stay away from BTRFS for web/email/database servers. Everything else seems fine.

It would be nice to include some real world tests, like creating and copying files around, boot time, etc.

[iq-0]

So it's probably a good idea to stay away from BTRFS for web/email/database servers. Everything else seems fine.

Well you probably want to use btrfs for the main system only the performance sensitive data partitions are probably better served using something like ext4, at least for the time being. But for many servers performance is not that critical and they too are possibly interested in advanced btrfs features like compression, data checksumming, snapshots and per-file raid like logic (at least for the filesystem metadata as that makes most of the FS more fault tolerant than ext4 could).