Announcement

Collapse
No announcement yet.

Linux 3.3 Kernel: Btrfs vs. EXT4

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

  • Linux 3.3 Kernel: Btrfs vs. EXT4

    Phoronix: Linux 3.3 Kernel: Btrfs vs. EXT4

    It's that time of the Linux kernel development cycle again... Here are benchmarks of the EXT4 and Btrfs file-systems with the soon-to-be-released Linux 3.3 kernel.

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

  • #2
    Disappointed by BTRFS

    I am disappointed by the stock performance of BTRFS. It has been said to be the next standard linux file system and it cant compete with ext4.
    Is transparent compression the only saving grace of BTRFS?

    Comment


    • #3
      Originally posted by mayankleoboy1 View Post
      I am disappointed by the stock performance of BTRFS. It has been said to be the next standard linux file system and it cant compete with ext4.
      Is transparent compression the only saving grace of BTRFS?
      Not sure if trolling...

      Default mount options are used. Besides, have you even looked at the features of btrfs?

      Comment


      • #4
        Originally posted by fackamato View Post
        Not sure if trolling...

        Default mount options are used. Besides, have you even looked at the features of btrfs?
        Obviously not, if he thinks transparent compression is the only thing btrfs can do that other linux filesystems can't.

        Comment


        • #5
          TBH I really would like seeing a MD-RAID0+BTRFS (and maybe MD-RAID+EXT4) <-> BTRFS-RAID0 comparison, and also the same for all other levels BTRFS currently supports (i.e. 1 and 10, with 5-6 in the pipeline IIRC).

          Comment


          • #6
            Benchmarks with features

            Thanks for the update Michael on the BTRFS development. I can't wait to see her stretch her legs when she gets into the wild.

            I'd like to see more benchmarks with different features of btrfs and ext4 turned on (besides SSD mode). Not only does this provide me with information about btrfs features, but information on what I might be able to squeeze out of the file system in terms of performance for my hard disk. These types of articles, for me, are small guides on how to get my hardware to function at its best.

            I've learned a lot from your compiler/mesa optimizations. Could you extend this to your file systems benchmarks?

            ~Much appreciated!

            Comment


            • #7
              Originally posted by phoronix View Post
              Phoronix: Linux 3.3 Kernel: Btrfs vs. EXT4

              It's that time of the Linux kernel development cycle again... Here are benchmarks of the EXT4 and Btrfs file-systems with the soon-to-be-released Linux 3.3 kernel.

              http://www.phoronix.com/vr.php?view=17111
              I'm very impressed with btrfs' performance.
              I can recall it being much slower than ext4 on pretty much every test, now, with stock butter, it is typically competitive.
              Presumably enabling compression would close the gap in every benchmark (obviously some more than others).
              So now, we need btrfs to have a file repair utility and online defrag for consumers.

              Comment


              • #8
                Anyone seen any % of compression for the different algorithms with filesystem level compression? I've seen a bunch of performance benchmarks, but none of the includes how much space you save, and I'm on an SSD so I'd be quite interested in that

                Comment


                • #9
                  Originally posted by neuron View Post
                  Anyone seen any % of compression for the different algorithms with filesystem level compression? I've seen a bunch of performance benchmarks, but none of the includes how much space you save, and I'm on an SSD so I'd be quite interested in that
                  If you're using a sandforce controller then the controller is already performing compression.

                  Comment


                  • #10
                    Originally posted by liam View Post
                    If you're using a sandforce controller then the controller is already performing compression.
                    .. which is not visible to the filesystem, so compression still matters a lot.

                    Comment


                    • #11
                      Originally posted by fackamato View Post
                      .. which is not visible to the filesystem, so compression still matters a lot.
                      It's not visible to the file system, but if you have a SF controller you shouldn't run filesystem level compression b/c it's superfluous. At best you may save a bit of space, but it will, in all cases, slow down your ops.
                      What is it I'm missing?

                      Comment


                      • #12
                        Any upcoming benchmark with transparent FS compression on Phoronix ?

                        Comment


                        • #13
                          Any upcoming benchmark with transparent FS compression on Phoronix ?
                          I'm sure that the data already exists to a usable degree. Does anyone know how to sort/filter OB to show btrfs results with compression?

                          http://openbenchmarking.org/s/btrfs

                          It would be nice to compare http://openbenchmarking.org/result/1...AR-BTRFSLZ4124 with http://openbenchmarking.org/result/1...BY-LINUX33BT16 and others in a single window and not have to switch between tabs.


                          F
                          Last edited by russofris; 03-03-2012, 11:04 AM.

                          Comment


                          • #14
                            Originally posted by mayankleoboy1 View Post
                            I am disappointed by the stock performance of BTRFS. It has been said to be the next standard linux file system and it cant compete with ext4.
                            Is transparent compression the only saving grace of BTRFS?
                            I don't see why you should be. At least not from these benchmarks. These benchmarks are artificial and only show very specific aspects of the file system... most of which is almost entirely irrelevant to most people's use cases. They really likely have very little bearing on what it is going to be like to run them in your desktop or a production system.

                            The principal advantage that Ext4 is going to have is that some of it's code is decades old and has hundred's of man-hours poured into it's development. It is very mature and there is very little that is going to surprise you with it and best practices are well established and widely known.

                            Btrfs on the other hand is going to require years of in-field usage and wide scale deployment before it can compete with Ext4 with that. But what Btrfs offers is significantly enhanced ability to manage data and from a administrative standpoint this is going to be invaluable once people learn to take advantage of it.

                            .. which is not visible to the filesystem, so compression still matters a lot.
                            Maybe, maybe not.

                            Most data people care about performance nowadays is already heavily compressed. If you care about, say, your ability to use Linux to manage multimedia files then compression is utterly irrelevant on the file system level and on the controller level. They use format-specific compression techniques and the chances of file system compression helping out is _NONE_AT_ALL_.

                            Now if you are dealing with thousands of plain text files ranging in size from 2MB to multiple GBs then compression is something that is probably going to matter a lot to you. That is, of course, you are not already using gzip or whatever to compress your data.

                            Comment


                            • #15
                              Originally posted by fackamato View Post
                              .. which is not visible to the filesystem, so compression still matters a lot.
                              The Sandforces compress all data they write, and reaching their advertised performance/endurance depends on the data written to them to be compressible. If you compress your data before that, you interfere with the controller doing its job properly, and waste the cpu cycles needed for filesystem compression.

                              Comment

                              Working...
                              X