Is there a best Linux file system?

Is there a best anything? Perhaps. I, personally, tend to think that home-made chocolate chip cookies are the best dessert. However, when it comes to file systems… there are no absolutes.

File systems come in all shapes and sizes; and where one may be perfect for a particular application or scenario – it may not be right for other use cases. This is where Red Hat Enterprise Linux 7 beta shines as it brings a variety of substantial enhancements to file systems in the form of scalability improvements, performance enhancements, and file system choices.

The big file system news in Red Hat Enterprise Linux 7 beta is that XFS will be the default file system for the boot, root, and user data partitions. Naturally, the existing ext4 file system (the default in Red Hat Enterprise Linux 6) will be fully supported, along with the earlier ext variants (ext2 and ext3). In fact, should you choose to stay with ext4, there is no requirement to leave – it will be an available option during the Red Hat Enterprise Linux 7 beta software installation.

Up above I had mentioned scalability improvements… in short, Red Hat Enterprise Linux 7 beta increases the maximum file system size limits for both XFS and ext4. For XFS, the maximum file system size limit increases from 100TB to 500TB while for ext4 it increases from 16TB to 50TB. For many workloads the file system choice will not have measurable impact on application performance but XFS will likely perform better than ext4, particularly in large scale configurations.

Expanding on performance, in case you haven’t heard of it, there is a new caching file system in Red Hat Enterprise Linux called FS-Cache. Initially delivered as Tech Preview in Red Hat Enterprise Linux 6, FS-Cache is a fully supported feature in the Red Hat Enterprise Linux 7 beta. It provides a persistent local cache that can be used by file systems to take data retrieved over the network and cache it on a local disk. This helps minimize network traffic for users accessing data from a file system mounted over the network (for example, NFS). FS-Cache can significantly reduce the network and server loading by satisfying read requests locally without consuming network bandwidth.

Finally, with respect to additional file system choices, Red Hat Enterprise Linux 7 beta allows for the use of Btrfs. Btrfs is a relatively young file system that has integrated basic volume management, snapshot support, and full data (and metadata) integrity checksumming. A guiding design criteria for Btrfs was a unified, easy to use, command line interface to drive advanced features. Without any additional hardware or external software, Btrfs is able to combine multiple drives into basic RAID sets and allows users to perform snapshots. It is a file system which emphasizes an ease of use that is well suited for non-enterprise, commodity hardware.

Note that file systems like Btrfs are included in the beta of Red Hat Enterprise Linux 7 because we know how critical new features like this are to our customers. While additional testing of Btrfs is required to ensure its readiness for production Red Hat Enterprise Linux environments, your feedback at this stage is important. With this in mind, for those with existing subscriptions, we encourage you to download the beta software and to let us know what you think!

Also, keep your eyes peeled for more information (from me) on file system enhancements in the Red Hat Enterprise Linux 7 beta. I plan to review how NFS updates can increase network performance and how a number of significant enhancements to the GFS2 shared disk file system can help boost overall system performance.

  1. Very interesting article, thanks for sharing!
    I’m currently having a look at the RHEL7 beta – and I’m very satisfied so far.

    Is there still the limitation that grown XFS file system can’t be shrinked again afterwards?

    Best regards from Germany,
    Christian Stankowic.

    1. Yes, correct. You can grow an XFS file system but not shrink one. It is worth noting that LVM support for thin provisioned volumes and space reclaimation/unmap may eliminate the need to resize file systems. They provide the ability to specify large volumes while consuming only the actual allocated storage resources.


  2. Please, we need online shrink! I currently work for an AIX shop and online shrink in JFS2 is a beautiful thing. If IBM can do it, surely you guys can too!

  3. Looks really exciting.

    Its just a bit sad that there’s nothing much of a break through, only slight improvement.
    I was expecting major improvements in XFS or maybe a new file system that gives even better performance than existing ones.

    1. Thanks for your comment. However I see the enhancements to XFS as significant, especially for large configurations. The addition of metadata CRC checksums enable quicker repair of very large file system configurations, and the supported file system size has increased the maximum XFS file system size from 100 TB to 500 TB.

      Regards, John.

  4. How about tools to recover XFS after system crash ? Do these exist with decent effectiveness ? How about tools to undelete files for XFS? Without I can’t see XFS being mature for production use

    1. Hello Michal and thank you for your question.
      Because XFS is a journaling filesystem, simply mounting it after a crash replays the journal and ensures filesystem consistency.

      If there is actual damage (not simply an unclean shutdown), xfs_repair can repair a corrupt or damaged filesystem. It is mature and highly scalable. See the xfs_repair(8) man page.

      There is not any supported xfs administration tool which performs an undelete. While there is an undelete facility in extN filesystems (the “undel” command for extN in debugfs) it’s a best-effort capability that is not guaranteed to work -> “if-it-breaks-you-keep-both-pieces” sort of thing.

      – John

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s