Announcement

Collapse
No announcement yet.

Btrfs Mount Option Performance Tuning On Linux 3.11

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

  • Btrfs Mount Option Performance Tuning On Linux 3.11

    Phoronix: Btrfs Mount Option Performance Tuning On Linux 3.11

    To complement the EXT4, XFS, Btrfs, and F2FS benchmark results that were published yesterday from the Linux 3.11 kernel and its predecessors, here are some Btrfs tuning benchmarks on the Linux 3.11 kernel with various performance-sensitive Btrfs mount options being tried.

    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
    how about nossd mount option + harddrive combination ?

    isn't ssd the default ?

    Comment


    • #3
      Thanks for the update on btrfs.
      I'm impressed they've managed to really decrease the delta between COW and no-COW.
      I've been using btrfs for root since around sept and haven't had any problems. Always fast, and never any data issues (use lzo and autodefrag).

      Comment


      • #4
        Originally posted by kernelOfTruth View Post
        how about nossd mount option + harddrive combination ?

        isn't ssd the default ?
        No, Btrfs figures out whether you have an HDD or an SSD automatically (by checking device properties). The ssd and nossd options are in case it's not detected correctly.

        Comment


        • #5
          It would be interesting to how btrfs performs agains zfs on freebsd. How feature complete is btrfs in comparison to zfs on freebsd in kernel 3.11 and freebsd 9.2 or the coming version 10?

          Comment


          • #6
            Well looks like the software LZO compression is beating the hardware compression of the Vertex 3's SandForce chip....

            Comment


            • #7
              skinny metadata

              It'd be interesting to see the benchmark results using btrfs' new skinny metadata/extents

              Comment


              • #8
                Originally posted by liam View Post
                Thanks for the update on btrfs.
                I'm impressed they've managed to really decrease the delta between COW and no-COW.
                I've been using btrfs for root since around sept and haven't had any problems. Always fast, and never any data issues (use lzo and autodefrag).
                I'm also using lzo + autodefrag. It seems to me like this combination is fairly common. I think there was some efficiency work done on autodefrag with the newest kernels, so it would be interesting to see how that affects things.

                Comment


                • #9
                  Originally posted by benmoran View Post
                  I'm also using lzo + autodefrag. It seems to me like this combination is fairly common. I think there was some efficiency work done on autodefrag with the newest kernels, so it would be interesting to see how that affects things.
                  Hardware:
                  Processor: Intel Core i7-3840QM @ 3.80GHz (8 Cores), Motherboard: CLEVO W240EU/W250EUQ/W270EUQ, Memory: 8192MB, Disk: 120GB OCZ AGILITY3, Graphics: Intel Ivybridge Mobile, Audio: VIA VT1802

                  Software:
                  OS: Gentoo 2.2, Kernel: 3.11.0-rc2-sjn-00243-g712d895 (x86_64), Desktop: GNOME Shell 3.8.3, Display Server: X Server 1.14.99.1, Display Driver: intel 2.21.12, OpenGL: 3.1 Mesa 9.2.0-devel (git-1903129), Compiler: Clang 3.3 + LLVM 3.3, File-System: btrfs, Screen Resolution: 1920x1080

                  Filesystem configuration:

                  Partition aligned at @4M

                  Btrfs create/mount options

                  16k leafsize
                  16k nodesize
                  4k sectorsize
                  TRIM (discard) enabled
                  disk space caching is enabled
                  skinny extents
                  lzo compression
                  inode map caching
                  auto defrag

                  Initial test shows I get twice the performance with fs-mark, if I get a chance and there's interest I'll run a full benchmark.

                  Comment


                  • #10
                    Autodefrag

                    Does anyone know if the benchmarks were performed by recreating the file system for each set of options, or just by remounting them?
                    If the files were created without autodefrag, the system could be bogged down defragging everything during the benchmark.

                    Comment

                    Working...
                    X