Announcement

Collapse
No announcement yet.

Linux 4.14 File-System Benchmarks: Btrfs, EXT4, F2FS, XFS

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

  • Linux 4.14 File-System Benchmarks: Btrfs, EXT4, F2FS, XFS

    Phoronix: Linux 4.14 File-System Benchmarks: Btrfs, EXT4, F2FS, XFS

    Our latest Linux file-system benchmarking is looking at the performance of the mainline Btrfs, EXT4, F2FS, and XFS file-systems on the Linux 4.14 kernel compared to 4.13 and 4.12.

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

  • #2
    Typo:

    Originally posted by phoronix View Post
    With CompileBench there were some fluctuations in the resutls but

    Comment


    • #3
      These synthetic benchmarks have always given me a wrong point of view on BTRFS, so in the beginning I was reluctant to use it. But after using it for both home computer and business NAS, I noticed that the real life difference between it and other filesystems is small. It ends up being a very good choice if you also count the extra features that you get with it.
      Last edited by EarthMind; 11-18-2017, 06:02 PM.

      Comment


      • #4
        It might be interesting to see what effect using scsi_mod.use_blk_mq=Y had on performance.
        I would expect a slight improvement with the single threaded test but possibly noticeable
        improvement on the multi-threaded tests. To make things interesting, things might
        vary by elevator: none, cfq, bfq, kyber.

        None of this qualifies as "out-of-the-box default" configuration, but it would supply
        data for the "next-generation" block module. Anecdotally, blk_mq seems faster,
        even for the none scheduler, but that is only the coarsest of data.

        Comment


        • #5
          Originally posted by EarthMind View Post
          These synthetic benchmarks have always given me a wrong point of view on BTRFS, so in the beginning I was never reluctant to use it. But after using it for both home computer and business NAS, I noticed that the real life difference between it and other filesystems is small. It ends up being a very good choice if you also count the extra features that you get with it.
          Indeed. It's the only one I've used for a long time. Snapshots/subvolumes and transparent compression are so nice.

          Comment


          • #6
            Indeed. I hope it will get broader acceptance on desktop mashines, especially concerning updates. Roling back to a snapshot after a update failed is a huge thing. And subvolumes instead of partitions should saves so mich disk space, not to mention compression and deduplication.

            One thing I really miss is native encryption. It would be really cool to have an encryption setup similar ios. On desktop systems, which quite often only get locked but not turned off, full-disk-encryption becomes less and less save, as the keys stay in memory.
            With native encryption, it would be possible to keep the keys for files nessecary to unlock the computer in ram, while others can only be read when the password is entered again.
            ext4 and friends offers this already as android is moving to a similar encryption setup.
            It's the only feature I can think of that btrfs lacks compared to them.

            Comment


            • #7
              why is btrfs so slow?

              Comment


              • #8
                Originally posted by sireangelus View Post
                why is btrfs so slow?
                Because of its features, checksumming on both data and metadata, and CoW (copy-on-write). No other filesystem in the test has a feature set comparable to btrfs.

                As others said though, it's less slow in real-life loads than it looks like in benchmarks.

                Comment


                • #9
                  Originally posted by treba View Post
                  Indeed. I hope it will get broader acceptance on desktop mashines, especially concerning updates. Roling back to a snapshot after a update failed is a huge thing. And subvolumes instead of partitions should saves so mich disk space, not to mention compression and deduplication.

                  One thing I really miss is native encryption. It would be really cool to have an encryption setup similar ios. On desktop systems, which quite often only get locked but not turned off, full-disk-encryption becomes less and less save, as the keys stay in memory.
                  With native encryption, it would be possible to keep the keys for files nessecary to unlock the computer in ram, while others can only be read when the password is entered again.
                  ext4 and friends offers this already as android is moving to a similar encryption setup.
                  It's the only feature I can think of that btrfs lacks compared to them.
                  This is true. I have a 512 GB SSD, and not allocating space for partitions in advance makes it so that I have all 512 GB available to /home, /, /var, and /opt, while maintaining partition-like separation between them.

                  Comment


                  • #10
                    Originally posted by sireangelus View Post
                    why is btrfs so slow?
                    actually it was fastest on two tests and same on third one
                    it is slow on non-real-life tests
                    it does cow, so you disable cow on databases or vms

                    Comment

                    Working...
                    X