Announcement

Collapse
No announcement yet.

Tuning Btrfs vs. F2FS, EXT4, XFS File-Systems

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

  • Tuning Btrfs vs. F2FS, EXT4, XFS File-Systems

    Phoronix: Tuning Btrfs vs. F2FS, EXT4, XFS File-Systems

    When earlier this week delivering Btrfs benchmarks with various mount options for tuning the next-generation Linux file-system, some Linux users were hoping to see other file-systems tossed into the test mix too for reference. Here's those numbers...

    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
    Now that ZFS on Linux is gaining in popularity and people are curious about it, especially in comparison to BTRFS, it may be worth it to throw it into the mix. Much more interesting then F2FS.

    Comment


    • #3
      A pity I have had such a great hope in BTRFS...

      Comment


      • #4
        Originally posted by Nuc!eoN View Post
        A pity I have had such a great hope in BTRFS...
        Real world performance, Nucleon? It works just fine. I jsut switched my Arch home server from EXT4 atop LVM cuz its got 2 disks, to BTRFS spread across two disks with compress=lzo (Seriously, how much simple could it be? "mkfs.btrfs /dev/sda1 /dev/sdb1" and youre done lol) and I literally dont notice any difference in it. The system also doubles as a linux desktop since my laptop runs windows 7 for power management reasons. Despite the APPARENT difference in performance via the benchmarking, in real world use you dont notice it. Also the simpler volume management, compression, snapshotting and built in integrity checking more than make up for any "loss" of performance.

        BTRFS isnt meant to be the fastest file system. When its fully done, its meant to be the safest.
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #5
          Hm, you might be right eric, it's just a bit shocking when looking at the benchmarks... I hope BTRFS will be able to at least get near the other filesystems. I wouldn't use BRTFS for productivity needs though, I can't imagine it's really stable for now.. remember this? Is it resolved actually? I can't find any reliable infos on it.

          Comment


          • #6
            Originally posted by Nuc!eoN View Post
            Hm, you might be right eric, it's just a bit shocking when looking at the benchmarks... I hope BTRFS will be able to at least get near the other filesystems. I wouldn't use BRTFS for productivity needs though, I can't imagine it's really stable for now.. remember this? Is it resolved actually? I can't find any reliable infos on it.
            That got resolved a long time ago haha. Basically what it came down to was a couple bugs, a little bad code, and the guy not actually understanding what he was complaining about. It got a lot of news, but not a lot of substance once you went into the mailing list and followed what everyone was talking about and the follow up thread a little while later.

            All of BTRFS' major issues have been resolved except MAYBE the VM performance (1 single large file that shouldnt be COW)

            Personally I've had one failure of BTRFS, and that was a power outage without a battery backup during a kernel upgrade on fedora 18, it hosed the filesystem. It MIGHT have been able to be fixed via fsck but since I had JUST installed it, I didnt really care and just reinstalled overtop haha.
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #7
              For the love of god!!! Michael, please, please, please stop doing filesystem comparisons.

              You are comparing one aspect (speed) of three classes of filesystem which have entirely different properties and uses, using unrealistic configurations.

              BTRFS is (or rather it will be when stabilised) a reliable-as-possible multi-spindle file system for maximum availability with bundles of features.
              Ext3 is a speedy day to day filesystem which you can afford to have down and even a little lost work while you recover the system from backups. It has no data integrity guarantees and misses many of the features and capabilities of BTRFS.
              XFS is similar to Ext3, except it was originally engineered for big filesystems/files and highly parallel workloads.
              F2FS is for flash memory and will be at a significant disadvantage on spinning media.

              No doubt if you do tests of ZFS (which is in the same class as BTRFS) as some are requesting, you will also do the same non-sensical comparison as if the speed were the only criteria that should inform peoples decisions.

              The golden rule applies here: If someone needs to know which is the fastest filesystem, they should take the time to test it in the configuration that will be used with a typical workload.

              Otherwise everyone should just look for a filesystem that provides features you need, and stop worrying about eeking out performance at the expense of data integrity.

              Comment


              • #8
                Am I the only one interested in this kind of comparison on a normal hard drive instead of SSD?

                Comment


                • #9
                  kiwi_kid_aka_bod: Why? It's interesting/useful/important to see how BTRFS performance develops over time.

                  Comment


                  • #10
                    A pity I have had such a great hope in BTRFS...
                    Ext3 and XFS are very mature and very fast file systems. Especially for database work Ext4 is going to very difficult to beat.

                    Things like BTRFS is going to be much more complex and more capabilities, but all that comes with extra overhead.

                    Plus most of BTRFS features are worthless if all you have is a single disk. The ability to do parities, checksums, scrub disks, etc etc are going to be of little use without any ability to recover corrupt data. For that you need at least 2 disks.

                    kiwi_kid_aka_bod: Why? It's interesting/useful/important to see how BTRFS performance develops over time.
                    If that is what Phoronix was actually doing then it would be fine.

                    These short little synthetic benchmarks are all easy to do, but it's hardly indicative of real-world performance. Even if you try to combine them it's not really going to let you know of real-world performance. Real file system benchmarks are very expensive to do. They require lots and lots of time. They require complex setup with real applications and loads created by using the system in a manner that is both realistic and can be repeated. One of the most important things you need to know is how the file system is going to behave when it gets full or when it gets old and starts fragmenting.

                    All the synthetic benchmarks really are doing is:
                    1. Format file system.
                    2. On fresh file system write as much data as possible.
                    3. Read it all back.
                    4. Maybe try a few different ways to do 2 and 3.
                    5. Repeat steps 2 through 4 10-12 times.

                    If you want good benchmarks you'll have to do a lot more work then that. Which is why almost nobody does it.

                    Comment

                    Working...
                    X