Announcement

Collapse
No announcement yet.

EXT4, Btrfs, NILFS2 Performance Benchmarks

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

  • EXT4, Btrfs, NILFS2 Performance Benchmarks

    Phoronix: EXT4, Btrfs, NILFS2 Performance Benchmarks

    The past few Linux kernel releases have brought a number of new file-systems to the Linux world, such as with EXT4 having been stabilized in the Linux 2.6.28 kernel, Btrfs being merged into Linux 2.6.29, and most recently the NILFS2 file-system premiering with the Linux 2.6.30 kernel. Other file-systems have been introduced too during the past few Linux kernel release cycles, but these three have been the most talked about and are often looked at as being the next-generation Linux file-systems. Being the benchmarking junkies that we are, we have set out to compare the file-system performance of EXT4, Btrfs, and NILFS2 under Ubuntu using the Linux 2.6.30 kernel. We also looked at how these file-systems compared to EXT3 and XFS.

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

  • #2
    I guess the performance advantage of ext3 vs ext4 in some benches are due to ext3 defaulting to writeback data mode in 2.6.30 while ext4 still defaults to the slower and more secure ordered data mode, so that's not exactly a fair comparison.

    Comment


    • #3
      Does this test used btrfs v0.19 from Jun 2009?

      First of all, thanks for the great articles! Phoronix is great!

      Btrfs developers were aware of lower performance from older benchmarks articles, as acknowledged here: http://btrfs.wiki.kernel.org/index.p...e#Benchmarking

      They delivered one improvement on v0.19:
      "In general, v0.19 is a dramatic speed improvement over v0.18 in almost every workload."
      http://btrfs.wiki.kernel.org/index.p....28Jun_2009.29

      Comment


      • #4
        btrfs v0.19 is post-2.6.30

        ... so the benchmark probably didn't consider the latest v0.19 yet perhaps.

        Comment


        • #5
          when the database numbers are as far off as they are in this test it makes me suspect that the fsyncs are being ignored by some filesystems and not by others. none of these filesystems are so far apart in design (except for possibly nilfs) that a 20x-60x variation is reasonable.

          Comment


          • #6
            Originally posted by andre.goddard View Post
            ... so the benchmark probably didn't consider the latest v0.19 yet perhaps.
            No it didn't. Linux 2.6.31 will include btrfs v0.19+ and therefore the dramatic performance improvements.

            Comment


            • #7
              What's the point of benchmarking btrfs just before a major format change?

              Comment


              • #8
                Red capslock text and reiser4 propaganda... where have I seen that before?

                Comment


                • #9
                  Yay! It's the crazy Reiser fan!

                  I've missed their rantings.

                  Also: MY THOUGHTS ON TEH GREAT JFS AND EXT2 CONSPIRACIES

                  But seriously though, looking at that I have a few quesions:

                  1) Does this mean we should just stick with EXT3?? Surely not.
                  2) What about deleting large files (mythtv)? Is XFS still the daddy for your 3.5TiB XFS partition containing all my myth media and every file is >2GiB?

                  J1M.

                  Comment


                  • #10
                    Originally posted by dlang View Post
                    when the database numbers are as far off as they are in this test it makes me suspect that the fsyncs are being ignored by some filesystems and not by others. none of these filesystems are so far apart in design (except for possibly nilfs) that a 20x-60x variation is reasonable.
                    You are probably right. Maybe this also explains why ZFS was 'slow' in SQLite in some previous Phoronix benchmark. As someone stated before such benchmarks will be more meaningful if we will see average CPU usage.

                    @Sleuth,

                    Get out of here with this bull....

                    Comment


                    • #11
                      Heh missed you Jeade :P

                      The article was about new filesystems -in kernel-. When Reiser4 is there, it'll see similar articles too.

                      Comment


                      • #12
                        Originally posted by curaga View Post
                        Heh missed you Jeade :P

                        The article was about new filesystems -in kernel-. When Reiser4 is there, it'll see similar articles too.
                        ++

                        seriously ! it would be nice to see several benchmarks of reiser4 and how it's comparing to the other filesystems (default format, gzip-, lzo-compression)

                        all filesystems shouldn't be mounted with default but with at least noatime,nodiratime

                        reiser4 and btrfs have several commonalities but also a lot of differences so I'm interested how they're stacking up against each other

                        @Sleuth:

                        I feel your pain

                        but in this way you won't resurrect his wife and pull him out of prison ...

                        Comment


                        • #13
                          Originally posted by Sleuth
                          Why do you not mention Reiser's filesystems?
                          Isn't it obvious?
                          Because Phoronix, whis is actually owned by jews, is part of the conspiracy to keep Reiser4 down. I also think that Michael himself murdered Reiser's wife and framed him for it.
                          Well, that'd be one reason. Or perhaps it's actually because Reiser4 is unmaintained, there's no way it's gonna be included in the mainline-kernel anytime soon and because it's all-around pretty much dead.
                          Your choose, I guess. I'd go with the second awnser. :P
                          Also: Welcome back Jade, long time no see. I thought you were banned?

                          Comment


                          • #14
                            The jew/ folder really ticked me off, so I wrote a short email to abuse?monkeysign?50webs? com

                            EDIT:
                            50webs removed the site.
                            thanks 50web!
                            Last edited by frische; 07-02-2009, 11:42 AM.

                            Comment


                            • #15
                              Extend Phoronix Test Suite disk tests?

                              Originally posted by RoboJ1M View Post
                              Yay! It's the crazy Reiser fan!

                              I've missed their rantings.

                              Also: MY THOUGHTS ON TEH GREAT JFS AND EXT2 CONSPIRACIES

                              But seriously though, looking at that I have a few quesions:

                              1) Does this mean we should just stick with EXT3?? Surely not.
                              My feeling from these results is that ext4 is the new general purpose filesystem for everyday use.

                              2) What about deleting large files (mythtv)? Is XFS still the daddy for your 3.5TiB XFS partition containing all my myth media and every file is >2GiB?
                              Now this would be a good new test for phoronix test suite, the time it takes to delete a single file of various sizes, along with deleting a directory tree of data recursively.

                              And of course, mixing up the reading and writing tests so they run at the same time and see which finishes first, and how much of an impact you have on each other. Esp since systems are reading and writing at the same time, so benchmarking that nicely would be useful.

                              Of course, you can go gaga on this type of testing, which is why they always say to benchmark your application as the true test. But for a desktop, general purpose system, doing a bunch of file operations in a mixed mode is always useful to see.

                              Some proposed tests:

                              - read/write a pair of 2/4/8gb files at the same time. Track the read and write times and put them side by side to see which finishes first, and how big the impact is on each other.

                              - time to delete 2/4/8gb single files.

                              - time to delete 2/4/8gb single file while reading/writing a single 2/4/8gb file. Measure jitter, response. Not sure how to show it graphically though.

                              - time to extract the linux kernel, recursively grep all the files for a pattern, then to delete the tree of files.

                              The overall aim is to see how filesystems perform under mixed loads, if at all possible.

                              John

                              Comment

                              Working...
                              X