Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39

Thread: Where The Btrfs Performance Is At Today

  1. #1
    Join Date
    Jan 2007
    Posts
    14,826

    Default Where The Btrfs Performance Is At Today

    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

  2. #2

    Default

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

  3. #3
    Join Date
    Jan 2009
    Posts
    4

    Default

    Quote Originally Posted by article
    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?

  4. #4
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    638

    Default

    Quote Originally Posted by ttxdragon View Post
    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

  5. #5
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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?

  6. #6
    Join Date
    May 2010
    Posts
    9

    Default

    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!

  7. #7
    Join Date
    Dec 2008
    Posts
    17

    Default

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

  8. #8
    Join Date
    Jun 2010
    Posts
    3

    Default More info needed

    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)

  9. #9
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    945

    Default

    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.

  10. #10
    Join Date
    Jun 2010
    Posts
    3

    Default

    Quote Originally Posted by devius View Post
    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).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •