Announcement

Collapse
No announcement yet.

With Linux 2.6.32, Btrfs Gains As EXT4 Recedes

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

  • With Linux 2.6.32, Btrfs Gains As EXT4 Recedes

    Phoronix: With Linux 2.6.32, Btrfs Gains As EXT4 Recedes

    We have published articles containing EXT4 benchmarks many times now going back to our original real world benchmarks of EXT4 to when Ubuntu 9.04 received EXT4 support and when we ran a variety of file-system benchmarks on an Intel X25-E SSD. We had also thrown in EXT4 numbers when benchmarking Btrfs (and again with Btrfs 0.19) along with NILFS2 benchmarks. Each time has been with a different kernel and the performance of the different Linux file-systems continue to change as each file-system matures and picks up different features. Though with the Linux 2.6.32 kernel the EXT4 performance had changed a great deal due to a change that provides better data integrity on writes but at a significant performance cost. To see how this changes the Linux file-system landscape, atop the latest Linux kernel we have a fresh set of benchmarks for EXT3, EXT4, XFS, ReiserFS, and Btrfs.

    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
    As far as I know, SSD mode is activated by default nowadays with btrfs. Are you sure it was disabled?

    Anyways, here's my future predictions:

    - btrfs will not be avaible with Ubuntu 10.04
    - btrfs will be avaible as an option for Ubuntu 10.10 which ships Linux 2.6.35/2.6.36
    - I will use btrfs with Ubuntu 10.10 and it will seriously rock
    - btrfs will become the default filesystem and replace ext4 in most mainstream distributions in early 2011

    Comment


    • #3
      Again. Strange comparison based upon Ubuntu system. Why?

      It should be noticed, that Ubuntu Ext3 does not use barriers by default in order to look much faster. But this is big lie, putting users data into the danger!

      Typical Ext3 speed on distribution, that care safety of users data, would be much slower in these graphs.

      Comment


      • #4
        btfrs seems to be just a slight change in ext4 to allow it to do the windows style rollback. I don't think I'm going to use it. It's great if you want to rollback system to previous time test something but even with all the faith I have in the linux guys it seems just a tad to dangerous for daily driver right now.
        I mean I'll download a couple hundred testing files and use the system like that with some occasional problems but btfrs seems a bit too scary for me.

        Comment


        • #5
          Originally posted by next9 View Post
          It should be noticed, that Ubuntu Ext3 does not use barriers by default in order to look much faster. But this is big lie, putting users data into the danger!

          Typical Ext3 speed on distribution, that care safety of users data, would be much slower in these graphs.
          I was/am suspicious of the Ext3 results - especially since when I moved from ext3 -> ext4 I found a huge performance boost in booting as did most others.

          Comment


          • #6
            Originally posted by d2kx View Post
            - btrfs will not be avaible with Ubuntu 10.04
            this one is wrong already.

            Comment


            • #7
              btfrs seems to be just a slight change in ext4 to allow it to do the windows style rollback. I don't think I'm going to use it. It's great if you want to rollback system to previous time test something but even with all the faith I have in the linux guys it seems just a tad to dangerous for daily driver right now.
              I mean I'll download a couple hundred testing files and use the system like that with some occasional problems but btfrs seems a bit too scary for me.
              Huh? Btrfs is a complete change in fs design compared to EXT4. It is COW, has filesystem compression, snapshots, dynamic inode allocation, etc, etc.

              It's not by any means a "slight change" although it is still experimental.

              Comment


              • #8
                Is the performance with a SSD meaningful for 'normal' systems?

                Hello,

                while it is nice to have an benchmark over the file systems I wonder how meaningful for 'normal' HDD-based system this benchmark is, considering a SSD was used.

                I think currently my hdd has 7200rpm and my next hard disk will probably only have 5400rpm for lower energy consumption. Which such devices the number of needed seeks is very important, while this effect does not really matter for a SSD. For me (and probably most other readers) the question how the file systems perform under this condition is currently the interesting one.

                For my system a SSD will probably only replace the HDD once I can get 1TB for around 100-150€, which will still take some time. ... Hm thinking about it a 128GB SSD combined with an 1.5TB HDD for <200€ will probably be a more realistic and not so far solution.
                Last edited by chlue; 14 December 2009, 11:02 AM.

                Comment


                • #9
                  I also find the EXT3 results quite dubious : I've never seen such a huge difference between EXT3 and XFS before, for instance, and actually prefer to use the second most of the time.
                  Maybe that comes from the lack of "barriers" which is not used in other distributions, since I've never extensively used Ubuntu.

                  Comment


                  • #10
                    retest

                    The end of the article alluded to running these tests with optimizations. SSD's are still an early-adopter technology, so I think it's safe to say that most SSD users will perform some level of optimization. Running the tests with everything at default is probably not indicative of the performance most of us will see. I think a better "default" test would be to use a different I/O scheduler (deadline and/or noop) and leave everything else at default. That way you don't have to run tests with risky mount options that could potentially compromise user data.

                    On a separate note, does anyone know what the advantages of using zlib compression on btrfs are?

                    Comment

                    Working...
                    X