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."..

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

  • #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


                    • #11
                      Why would you want to run a fast filesystem? I dont get it.

                      The most important thing for a filesystem is data integrity. Is your data safe and protected on disk? With XFS, the answer is no.

                      http://www.zdnet.com/blog/storage/ho...ta-at-risk/169
                      A researcher shows that:

                      "XFS, NTFS, ext3, ReiserFS and JFS have. . . failure policies that are often inconsistent, sometimes buggy, and generally inadequate in their ability to recover from partial disk failures."

                      I would not want to put my data on a fast, but not reliable storage solution. Data safety is the most important for me. Not speed.

                      Comment


                      • #12
                        Originally posted by kebabbert View Post
                        Why would you want to run a fast filesystem? I dont get it.

                        The most important thing for a filesystem is data integrity. Is your data safe and protected on disk? With XFS, the answer is no.

                        http://www.zdnet.com/blog/storage/ho...ta-at-risk/169
                        A researcher shows that:

                        "XFS, NTFS, ext3, ReiserFS and JFS have. . . failure policies that are often inconsistent, sometimes buggy, and generally inadequate in their ability to recover from partial disk failures."

                        I would not want to put my data on a fast, but not reliable storage solution. Data safety is the most important for me. Not speed.
                        There are plenty of cases where speed might be more important than data integrity. Look at Google, for instance. They might not care if a rare (and they really must be rare, of course) error occurs as long as they can get superior speed out of the filesystem. After all, they hopefully have data integrity anyway across many different disks in their network, and they're constantly updating the data anyway which would remove any temporary errors. While a problem in speed directly effects the user experience and requires Google to spend more money on hardware to make up for it.

                        Not that I'm saying that's typical, just that sweeping statements like you tend to make can be just as wrong. No single scenario covers 100% of people.

                        Comment


                        • #13
                          Originally posted by kebabbert View Post
                          I would not want to put my data on a fast, but not reliable storage solution. Data safety is the most important for me. Not speed.
                          This is why I always use data journalling on ext4 partitions, because until I did so they required manual fscks on reboots on a regular basis.

                          Comment


                          • #14
                            Originally posted by kebabbert View Post
                            Why would you want to run a fast filesystem? I dont get it.

                            The most important thing for a filesystem is data integrity.
                            For most people, yes. But some big setups find performance more important than the reliability of a single disk, achieving integrity through massive redundancy of the data.

                            That's not to say that an outright-flaky filesystem is acceptable. But as long as you know when failures occur and they don't occur often, it may be cheaper to tolerate those failures than to use a different filesystem that never loses data but is significantly slower.

                            Comment


                            • #15
                              Can't the devs just test and fix their crap before they release new version of kernel. I can't remember a kernel where something wasn't fscked up the filesystem that affects destop use.

                              Comment

                              Working...
                              X