Announcement

Collapse
No announcement yet.

Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10

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

  • Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10

    Phoronix: Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10

    Building upon our F2FS file-system benchmarks from earlier in this week is a large comparison of four of the leading Linux file-systems at the moment: Btrfs, EXT4, XFS, and F2FS. With the four Linux kernel file-systems, each was benchmarked on the Linux 3.8, 3.9, and 3.10-rc1 kernels. The results from this large file-system comparison when backed by a solid-state drive are now published on Phoronix.

    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
    The next set of benchmarks better have btrfs told to compress with lzo, otherwise you're not really testing btrfs in a way that would be used real world.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #3
      For btrfs, are you turning off COW for database file(s) for the database-driven tests?

      Comment


      • #4
        Originally posted by Ericg View Post
        The next set of benchmarks better have btrfs told to compress with lzo, otherwise you're not really testing btrfs in a way that would be used real world.
        That would break many benchmarks. Notice that test files are often full of zeroes, yielding unrealistic benefits. Real world data isn't anything like that.

        Comment


        • #5
          Originally posted by rvalles View Post
          That would break many benchmarks. Notice that test files are often full of zeroes, yielding unrealistic benefits. Real world data isn't anything like that.
          True, wasn't thinking about the fact that he just does zero-filled files instead of random-filled
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #6
            Other OS tests

            It would be interesting to get an idea of what that hardware can do under NTFS or OSX, for comparison. For example, btrfs looks pretty bad compared to ext4, but i wonder if it's competitive with what you'd see on other OS's. In other words, is btrfs really struggling, or is ext4 just really good?

            Comment


            • #7
              With ZFS finally being declared stable on linux, it should really be included in these benchmarks. It is an excellent comparison for btrfs, since they are both COW, modern filesystems, which can lead to performance penalties compared to conventional filesystems like ext4 or XFS.

              Comment


              • #8
                Originally posted by smitty3268 View Post
                It would be interesting to get an idea of what that hardware can do under NTFS or OSX, for comparison. For example, btrfs looks pretty bad compared to ext4, but i wonder if it's competitive with what you'd see on other OS's. In other words, is btrfs really struggling, or is ext4 just really good?
                Btrfs has different features. But what would be worthwhile is to test NTFS (as a counterpart to EXT4) and ResFS (as a counterpart to Btrfs) on Windows.

                Comment


                • #9
                  btrfstune

                  Michael, in 3.10, btrfs has gained skinny metadata support. It'd be interesting to benchmark btrfs with that feature turned on (needs btrfstune).

                  Comment


                  • #10
                    If you choose your filesystem based on a bunch of artificial benchmarks that show how "fast" it is, you are an idiot!

                    Choose a filesystem based on requirements and testing. If you have only the requirement for it go really fast, then sure, these could inform your decision, but you should still test with your own workloads. This is however a very specialized subset of people (pros doing video editing, photoshop artists, CERN etc.) that need outrageous speed when editing or during experiments. For long term storage these people will still be using one of the "slow" filesystems that actually protect their data.

                    Everyone else should pick the filesystem with the best data integrity and resiliance. You will likely never notice loss of "speed" what with continuous improvements in hardware, caching and prefetch of data.

                    Comment

                    Working...
                    X