Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Btrfs File-System Tuning On Linux 3.7

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

    Default Btrfs File-System Tuning On Linux 3.7

    Phoronix: Btrfs File-System Tuning On Linux 3.7

    Earlier this week I posted new Reiser4 file-system benchmarks that compared the non-mainline file-system against EXT4, Btrfs, XFS, and ReiserFS. Continuing in the Linux file-system performance theme, in this article are more Btrfs benchmarks from that same system but when using the early Linux 3.7 development kernel and trying out different Btrfs mount/tuning options.

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

  2. #2
    Join Date
    Dec 2008
    Posts
    146

    Default

    Why does noatime produce a significant SLOWDOWN in some of the tests (IOzone, threaded-IO)? This makes no sense to me. Is it a bug in btrfs, or in the benchmark tests, or something else?

  3. #3
    Join Date
    Jul 2012
    Posts
    757

    Default

    Is there a similar benchmark for ext4? I'm currently using noatime and discard for mounting it.

  4. #4
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,554

    Default

    Interesting benchmark there. Good to know that inode caching has a (minimal) positive effect.

    And yeah, lzo compression seems to lead to lolspeeds.

  5. #5
    Join Date
    Dec 2008
    Posts
    146

    Default

    Quote Originally Posted by GreatEmerald View Post
    And yeah, lzo compression seems to lead to lolspeeds.
    That is not very meaningful, since several of the benchmark programs write unrealistic highly compressible data (streams of zeros). With real data, the compression options will have only a small effect.

  6. #6
    Join Date
    Sep 2007
    Posts
    313

    Default

    Quote Originally Posted by jwilliams View Post
    Why does noatime produce a significant SLOWDOWN in some of the tests (IOzone, threaded-IO)? This makes no sense to me. Is it a bug in btrfs, or in the benchmark tests, or something else?
    +1

    And is there any reason, why lzo should not be enabled by default when using a modern processor? It probably won't be able to compress already compressed data. Yet, would it make the disc usage in this cases worse?

  7. #7
    Join Date
    Dec 2011
    Posts
    38

    Default

    Quote Originally Posted by oleid View Post
    +1

    And is there any reason, why lzo should not be enabled by default when using a modern processor? It probably won't be able to compress already compressed data. Yet, would it make the disc usage in this cases worse?
    i test btrfs recently (with a sandy bridge processor), it seems that compression will introduce the following side effect

    1. The maximum size of extent will be limited to 256K, leading to heavier fragmentation and more metadata
    2. increase latency when read, my VM is slower when compression is on

    btrfs might need to decompress the whole extent before reading even one byte

    3. bootloader may not support corresponding compression
    Last edited by unknown2; 10-19-2012 at 04:48 AM.

  8. #8
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,554

    Default

    Quote Originally Posted by jwilliams View Post
    That is not very meaningful, since several of the benchmark programs write unrealistic highly compressible data (streams of zeros). With real data, the compression options will have only a small effect.
    Yea, I know. But there should still be a bit of performance boost, as well as disk space boost.

    Quote Originally Posted by oleid View Post
    And is there any reason, why lzo should not be enabled by default when using a modern processor? It probably won't be able to compress already compressed data.
    Btrfs doesn't compress already compressed data by default. It figures out what is and what isn't compressed already automatically.

  9. #9
    Join Date
    Jun 2010
    Location
    Italy
    Posts
    20

    Default

    Not counting the fact that there is n update to latest lzo compression alghoritm proposed for mainline:
    [GIT PULL v2] Update LZO compression
    that is typically more than 2 times faster!

    Marco

  10. #10
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    NEEDS RELIABILITY TESTING PLEASE!

    Means fault tolerance(how good it resists damage) and fault chance(how often software-dependent/brtfs-driver faults happen)

    please!!!

Posting Permissions

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