Announcement

Collapse
No announcement yet.

Ted Ts'o: EXT4 Within Striking Distance Of XFS

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

  • Ted Ts'o: EXT4 Within Striking Distance Of XFS

    Phoronix: Ted Ts'o: EXT4 Within Striking Distance Of XFS

    There's just two months to go until the annual Linux.Conf.Au conference, which in 2011 is taking place in Brisbane, Australia. Ted Ts'o, the maintainer of the EXT4, will be speaking at the 2011 Linux.Conf.Au and he's just shared his "money shot" from his presentation about this evolutionary file-system building atop EXT2/EXT3. New benchmarking results from HP's Eric Whitney on a large multi-core system indicate that "[EXT4 is] now within striking distance of XFS."..

    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
    Ted Ts'o, the maintainer of the EXT4, [...] just shared his "money shot" from his presentation
    Thanks for that image, Michael. :\

    Comment


    • #3
      Let me get this stright: is xfs _with_ journaling still faster than ext4 _without_ journaling in that test?
      Who wants a business-grade filesystem without journaling?

      Comment


      • #4
        Why don't you look at the graph in the linked blog post? There isn't much difference between ext4+journal and ext4-journal.

        Yes, XFS is still faster in the tested scenario. The point is that EXT4 got a huge speed boost on systems with many cores/threads and gets close to XFS, which had previously been all alone in that segment.

        Comment


        • #5
          What's the point of a journaling filesystem like ext4 without active journaling? And i think the difference with many threads is still huge.

          Comment


          • #6
            This isn't too surprising. XFS is a production-quality, mature filesystem that does extremely well for certain workloads, and manages to pull respectable performance even in sub-optimal workloads. Plus I have never lost data on an XFS system. EXT4 is a spring chicken by comparison. It will still be a few years until Btrfs or EXT4 have the long history and ruggedness of XFS, and as many of Michael's articles show, EXT4 has some pretty severe slow paths for certain operations.

            Comment


            • #7
              Originally posted by rohcQaH View Post
              Why don't you look at the graph in the linked blog post? There isn't much difference between ext4+journal and ext4-journal.
              I did look at those graphs. At 192 threads the difference between journal and no journal on ext4 is in the range of 30-40%. I think this is a big difference.

              Originally posted by rohcQaH View Post
              Yes, XFS is still faster in the tested scenario. The point is that EXT4 got a huge speed boost on systems with many cores/threads and gets close to XFS, which had previously been all alone in that segment.
              I agree. The patches almost tripled ext4 performance in that scenario (which btw, is of no interest for any home user, and most likely will not be in any foreseeable future).

              Comment


              • #8
                ext4 is faster with current 2.6.36 for me than xfs - so

                (I'm a desktop/home-user so that doesn't tell much about ext4' scalability abilities )

                Comment


                • #9
                  Originally posted by misiu_mp View Post
                  Let me get this stright: is xfs _with_ journaling still faster than ext4 _without_ journaling in that test?
                  Who wants a business-grade filesystem without journaling?
                  Journaling is the best way to go in case of a crash for sure, and optimizing journaling would be a good way to reduce the performance hit though.

                  Comment


                  • #10
                    A filesystem where a simple rename can result in complete data loss is a bad, stupid joke.

                    BTRFS is infected with the same idiocy. There is something more important than speed:
                    Data.

                    Resier4 was able to guarantee atomicity years ago - and its 'layer violations' are less blatant than the ones of BTRFS. One is in the kernel, the other is not.

                    Idiocy.

                    Comment

                    Working...
                    X