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

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

  1. #1
    Join Date
    Jan 2007
    Posts
    13,396

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

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

  2. #2
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,739

    Default

    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.

  3. #3
    Join Date
    Dec 2010
    Posts
    45

    Default

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

  4. #4
    Join Date
    Mar 2012
    Posts
    43

    Default

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

  5. #5
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,739

    Default

    Quote 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

  6. #6
    Join Date
    Oct 2008
    Posts
    2,904

    Default 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?

  7. #7
    Join Date
    Dec 2008
    Posts
    145

    Default

    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.

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

    Default

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

  9. #9
    Join Date
    Nov 2010
    Posts
    100

    Default 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).

  10. #10

    Default

    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.

Posting Permissions

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