Announcement

Collapse
No announcement yet.

Btrfs File-System Tuning On Linux 3.7

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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?

    Comment


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

      Comment


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

        And yeah, lzo compression seems to lead to lolspeeds.

        Comment


        • #5
          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.

          Comment


          • #6
            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?

            Comment


            • #7
              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; 19 October 2012, 04:48 AM.

              Comment


              • #8
                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.

                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.

                Comment


                • #9
                  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

                  Comment


                  • #10
                    NEEDS RELIABILITY TESTING PLEASE!

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

                    please!!!

                    Comment

                    Working...
                    X