Red Hat support for XFS

It’s a royal pain to actually get it, but Red Hat officially started supporting XFS as a “layered product” in RHEL 5.4 (about a year ago).

Why might you want to use XFS? Well, take a look at the benchmarks released this week from Eric Whitney at HP. Short version: XFS is the fastest, scales to multiple threads the best, and uses the least CPU (for this workload).

I used to be ambivalent about recommending XFS, in part because SGI imploded and many of the XFS developers scattered to the winds. But now several of the top XFS developers are working for Red Hat, including:

Between the three of them, they have written:

  • 77% of commits in the last year to fs/xfs/
  • 58% of commits in the last 5 years to fs/xfs/
  • 62% of commits in the last year to xfsprogs
  • 17% of all commits to xfsprogs

So I personally feel pretty confident that Red Hat has the in-house talent to support our customers who want to use XFS.

Disclaimers:

Counts include merge commits. The date ranges are approximate since I just looked for a commit around the date I wanted and included all the commits in a straight line since that commit, but due to merges, commits aren’t in strict chronological order. The mainline Linux kernel only has accurate commit info back to April 2005. Finally, the git history may be in error; this is part of why it’s so important to get commit attribution correct.

As always, I don’t speak officially for Red Hat in this or any other blog post.

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

5 Responses to Red Hat support for XFS

  1. Bill Weiss says:

    For a very particular workload I had in a previous job, XFS was the only choice because it does deletes in O(1) instead of the O(N) of ext{2,3}. At the time (RHEL 5.2?) our RedHat support person couldn’t really comprehend that this was a problem for us, so we had to go with someone’s hacked-up third party package. I’m glad to see they’ve come to their senses on the issue.

  2. Alex Bennee says:

    I have to say I’d always thought XFS was a legacy file-system given all the “cool kids” were working on improving ext and brtfs with the aspiration of reaching the functionality of ZFS on Solaris. However our sysadmin at work has just migrated the multi-terrabyte/millions of files engineering server over to XFS (from ext3 IIRC) and he can’t sing the praises of it enough.

  3. Tet says:

    The amusing thing there is that Ted is using those very same benchmarks to show how good ext4 is getting :-)

    http://thunk.org/tytso/blog/2010/11/01/i-have-the-money-shot-for-my-lca-presentation/

  4. tlw says:

    Weird.

    We have been shipping a product in which we use XFS for one of the (most important) partitions — it’s been nothing but a nightmare! Every other day we have customers calling to say “somthing’s not working right” and when we investigate we find massive data corruption in the XFS partition. So we started doing simple tests, and we can’t find a single instance where we don’t get errors all over the place with even the most basic operations (forget power failures or pulling the plug, just a simple install!). We’ve been quietly but quickly switching our product and customers over to extN before this blows up in our faces!

    But everything I hear about XFS is how awesome it is. If correct operation isn’t important, then yea, “we can go *really* fast” :-)

    Maybe we’re doing something wrong(?)

    • vaurora says:

      It would be foolish to debug a file systems corruption problem in the comments to a blog post. :) However, I would definitely suspect some sort of interaction between hardware and what the file system happens to do, since, frankly, XFS is better than that. Sometimes you will see corruption with one file system and not another file system, not because one file system is wrong, but because one happens to trigger some underlying bug and the other does not.

      I’d check:

      * write cache settings on the hardware
      * barrier settings on the file system
      * log options on the file system

Comments are closed.