Page 1 of 5 123 ... LastLast
Results 1 to 10 of 67

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

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,652

    Default 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. #2
    Join Date
    Mar 2007
    Posts
    48

    Default

    Ted Ts'o, the maintainer of the EXT4, [...] just shared his "money shot" from his presentation
    Thanks for that image, Michael. :\

  3. #3
    Join Date
    Oct 2007
    Location
    Sweden
    Posts
    174

    Default

    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?

  4. #4
    Join Date
    Nov 2008
    Posts
    784

    Default

    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.

  5. #5
    Join Date
    Dec 2009
    Posts
    77

    Default

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

  6. #6
    Join Date
    Feb 2009
    Posts
    22

    Default Why we benchmark ext4 in no journal mode

    Quote Originally Posted by Lynxeye View Post
    What's the point of a journaling filesystem like ext4 without active journaling? And i think the difference with many threads is still huge.
    There are two reasons why I asked Eric to benchmark ext4 in no journal mode.

    First of all, if you are using ext4 as the object store for a cluster filesystem, where you might have hundreds of servers in your cluster file system, with perhaps thousands of disks, and where each file is composed of "shards" which are replicated on multiple servers for redundancy in case a server dies (maybe the hard drive craps out, or a power supply explodes, etc; when you have that many servers, the probability of some machine failing approaches 100%). In that scenario, the journal is overhead that's not worth the cost.

    (Note by the way that the "large file creates" workload is not a metadata heavy workload; so the effect of the journal is not that pronounced. The "mail server" workload has a many more metadata changes per transaction, and we see a much more pronounced differences between the journal and no journal modes with 1 threads. The fact that differences fall off at 48 and 192 threads is because we still have scalability bottlenecks in the journal code that I still need to fix up.)

    The second reason why I asked Eric to benchmark ext4 in journal and no journal mode is that it helps me to see where potential bottlenecks are in ext4, so I know what is most profitable to tackle next. The main thrust of my LCA talk is actually about how to decide what optimizations to do next to improve a kernel system's scalability. If you look at the three benchmark reports which Eric produced for the work that I did during 2.6.34, 2.6.35, and 2.6.36, the lockstat report showed me where the ext4 code was hitting bottlenecks, and that told me what I should do next in order to make ext4 more scalable.

    It would be awfully nice if the Phoronix benchmarks actually gathered information using perf and lockstat, since that is actually what we kernel developers need to help see how to improve the benchmarks. In fact, the graphs are pretty, but they are not what we need to understand how we can improve the filesystem. The graphs are what ESPN shows when they do 15 second clips of receives catching touchdown passes; it may drive advertising revenue, but it doesn't help the football players improve their game. For that we need to study the game films, in slow motion, and from multiple angles, and we need to study a lot more than just the receive catching the touchdown pass. How the offensive and defensive linemen react to the play, etc., is far more important.

  7. #7
    Join Date
    Oct 2007
    Location
    Sweden
    Posts
    174

    Default

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

    Quote 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).

  8. #8
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    642

    Default

    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 )

  9. #9
    Join Date
    Feb 2009
    Posts
    22

    Default It's not about competition!

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

    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.
    If people are fixated on "win-loss" graphs, see the "random write" and "mail server" workloads, where ext4 actually does better than XFS. But really, I'm not seeing this primarily as an ext4 vs. XFS thing. If I had, I would have pointed at those graphs instead, and done the fanboy "Nyah, nyah" thing.

    We benchmark ourselves against XFS as a mark of respect. XFS has been optimized for HPC workloads where they are often writing large files to large raid arrays from big systems. (For SGI, 48 cores is a small system.) So the "large file create" workload, on the given hardware configuration, is basically on XFS's home ground, and as that graphs shows, we still have more work to do.

    Some people like to treat file system benchmarks as a competition, and want to score wins and losses. That's not the way I look at it. I hack file systems because I'm passionate about working on that technology. I'm more excited about how I can make ext4 better, and not whether I can "beat down" some other file system. That's not what it's all about.

    -- Ted

  10. #10
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    Quote Originally Posted by tytso View Post
    Some people like to treat file system benchmarks as a competition, and want to score wins and losses. That's not the way I look at it. I hack file systems because I'm passionate about working on that technology. I'm more excited about how I can make ext4 better, and not whether I can "beat down" some other file system. That's not what it's all about.

    -- Ted
    That's a hell of a quote. Respect.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •