Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 1. Overview of available file systems

Choosing the file system that is appropriate for your application is an important decision due to the large number of options available and the choices to consider.

The following sections describe the file systems that Red Hat Enterprise Linux 10 includes by default, and recommendations on the most suitable file system for your application.

1.1. Types of file systems
Copier lien

Red Hat Enterprise Linux 10 supports a variety of file systems (FS). Different types of file systems solve different kinds of problems, and their usage is application specific.

At the most general level, available file systems can be grouped into the following major types:

Expand
Table 1.1. Types of file systems and their use cases
TypeFile systemAttributes and use cases

Disk or local FS

XFS

XFS is the default file system in RHEL. Deploy XFS as your local file system unless there are specific reasons to do otherwise. For example, compatibility or corner cases around performance.

ext4

ext4 has the benefit of familiarity in Linux, having evolved from the older ext2 and ext3 file systems. In many cases, it rivals XFS on performance. Support limits for ext4 file system and file sizes are lower than those on XFS.

Network or client-and-server FS

Network File System (NFS)

Use NFS to share files between multiple systems on the same network.

Server Message Block (SMB)

Use SMB for file sharing with Microsoft Windows systems.

Volume-managing FS

Stratis

Stratis is a volume manager built on a combination of XFS and Logical Volume Manager (LVM). The purpose of Stratis is to emulate capabilities offered by volume-managing file systems like Btrfs and ZFS. It is possible to build this stack manually, but Stratis reduces configuration complexity, implements best practices, and consolidates error information.

1.2. Local file systems
Copier lien

Local file systems run on one server with directly attached storage. They are used for internal Serial Advanced Technology Attachment (SATA) or Serial Attached SCSI (SAS) disks, hardware RAID, and non-shared SAN devices.

All local file systems follow Portable Operating System Interface (POSIX) standards and provide support for a well-defined set of system calls. Examples include read(), write(), and seek().

Available local file systems
  • XFS
  • ext4

1.3. The XFS file system
Copier lien

XFS is a highly scalable, high-performance, robust, and mature 64-bit journaling file system. It supports very large files and file systems on a single host. It is the default file system in Red Hat Enterprise Linux 10. XFS was originally developed in the early 1990s by SGI and has a long history of running on extremely large servers and storage arrays.

The features of XFS include:

Reliability
  • Metadata journaling ensures file system integrity after a system crash. It keeps a record of file system operations. These records can be replayed when the system restarts and the file system is remounted.
  • Extensive run-time metadata consistency checking
  • Scalable and fast repair utilities
  • Quota journaling. This avoids the need for lengthy quota consistency checks after a crash.
Scalability and performance
  • Supported file system size up to 1024 TiB
  • Ability to support a large number of concurrent operations
  • B-tree indexing for scalability of free space management
  • Sophisticated metadata read-ahead algorithms
  • Optimizations for streaming video workloads
Allocation schemes
  • Extent-based allocation
  • Stripe-aware allocation policies
  • Delayed allocation
  • Space pre-allocation
  • Dynamically allocated inodes
Other features
  • Reflink-based file copies
  • Tightly integrated backup and restore utilities
  • Online defragmentation
  • Online file system growing
  • Comprehensive diagnostics capabilities
  • Extended attributes (xattr). With this, the system can associate several additional name/value pairs per file.
  • Project or directory quotas for quota restrictions over a directory tree.
  • Subsecond timestamps
Performance characteristics

XFS has high performance on large systems with enterprise workloads. A large system is one with a relatively high number of CPUs, multiple HBAs, and connections to external disk arrays. XFS also performs well on smaller systems that have a multi-threaded, parallel I/O workload.

XFS performs comparably well on smaller systems, but is more focused on scalability and large data sets.

1.4. The ext4 file system
Copier lien

The ext4 file system is the fourth generation of the ext file system family. The ext4 driver can read and write to ext2 and ext3 file systems. However, the ext4 file system format is not compatible with ext2 and ext3 drivers.

ext4 adds several new and improved features, such as:

  • Supported file system size up to 50 TiB
  • Extent-based metadata
  • Delayed allocation
  • Journal checksumming
  • Large storage support

The extent-based metadata and the delayed allocation features help to track utilized space in a file system. These features improve file system performance and reduce the space consumed by metadata. The file system postpones selecting the permanent location for newly written user data because of delayed allocation.

The location is chosen only when the data is flushed to disk. This causes higher performance since it can allow for larger, more contiguous allocations. The file system can make decisions with much better information.

File system repair time by using the fsck utility in ext4 is much faster than in ext2 and ext3. Some file system repairs have demonstrated up to a six-fold increase in performance.

1.5. Comparison of XFS and ext4
Copier lien

XFS is the default file system in RHEL. This section compares the usage and features of XFS and ext4.

Metadata error behavior
In ext4, you can configure the behavior when the file system encounters metadata errors. The default behavior is to continue the operation. When XFS encounters an unrecoverable metadata error, it shuts down the file system and returns the EFSCORRUPTED error. XFS also supports configurable error handling.
Quotas

In ext4, you can enable quotas when creating the file system or later on an existing file system. You can then configure the quota enforcement by using a mount option.

XFS quotas are not a remountable option. You must activate quotas on the initial mount.

Running the quotacheck command on an XFS file system has no effect. The first time you turn on quota accounting, XFS checks quotas automatically.

File system resize
XFS has no utility to reduce the size of a file system. You can only increase the size of an XFS file system. In comparison, ext4 supports both extending and reducing the size of a file system. However, shrinking is only an offline operation.
Inode numbers

The ext4 file system does not support more than 232 inodes.

XFS supports dynamic inode allocation. The amount of space inodes can consume on an XFS filesystem is calculated as a percentage of the total filesystem space. To prevent the system from running out of inodes, an administrator can tune this percentage after the filesystem has been created. To prevent the system from running out of inodes, an administrator can tune this percentage after the file system has been created. This is possible when there is free space available on the file system.

Certain applications cannot properly handle inode numbers larger than 232 on an XFS file system. These applications might cause the failure of 32-bit stat calls with the EOVERFLOW return value. Inode number exceed 232 under the following conditions:

  • The file system is larger than 1 TiB with 256-byte inodes.
  • The file system is larger than 2 TiB with 512-byte inodes.

If your application fails with large inode numbers, mount the XFS file system with the -o inode32 option to enforce inode numbers below 232. Using inode32 does not affect inodes that are already allocated with 64-bit numbers.

Important

Do not use the inode32 option unless a specific environment requires it. The inode32 option changes allocation behavior. As a consequence, the ENOSPC error might occur if no space is available to allocate inodes in the lower disk blocks.

1.6. Choosing a local file system
Copier lien

To choose a file system that meets your application requirements, you must understand the target system on which you deploy the file system. In general, use XFS unless you have a specific use case for ext4.

XFS
For large-scale deployments, use XFS, particularly when handling large files (hundreds of megabytes) and high I/O concurrency. XFS performs optimally in environments with high bandwidth (greater than 200MB/s) and more than 1000 Input/Output Operations Per Second (IOPS). However, it consumes more CPU resources for metadata operations compared to ext4 and does not support file system shrinking.
ext4
For smaller systems or environments with limited I/O bandwidth, ext4 might be a better fit. It performs better in single-threaded, lower I/O workloads and environments with lower throughput requirements. ext4 also supports offline shrinking, which can be beneficial if resizing the file system is a requirement.

Benchmark your application’s performance on your target server and storage system to ensure the selected file system meets your performance and scalability requirements.

Expand
Table 1.2. Summary of suitable use cases for file systems
ScenarioRecommended file system

No special use case

XFS

Large server

XFS

Large storage devices

XFS

Large files

XFS

Multi-threaded I/O

XFS

Single-threaded I/O

XFS, ext4

Limited I/O capability (under 1000 IOPS)

XFS, ext4

Limited bandwidth (under 200MB/s)

XFS, ext4

CPU-bound workload

XFS, ext4

Support for offline shrinking

XFS, ext4

1.7. Network file systems
Copier lien

Network file systems, also referred to as client/server file systems, provide client systems with access to files that are stored on a shared server. This makes it possible for multiple users on multiple systems to share files and storage resources.

Such file systems are built from one or more servers that export a set of file systems to one or more clients. The client nodes do not have access to the underlying block storage. Instead, they interact with the storage by using a protocol that allows for better access control.

Available network file systems
  • The most common client/server file system for RHEL customers is the Network File Systems (NFS). RHEL provides both an NFS server component to export a local file system over the network and an NFS client to import these file systems.
  • RHEL also includes a Common Internet File System (CIFS) client. This supports the popular Microsoft Server Message Block (SMB) file servers for Windows interoperability. The userspace Samba server provides Windows clients with a Microsoft SMB service from a RHEL server.

1.8. Shared storage file systems
Copier lien

Shared storage file systems, sometimes known as cluster file systems, give each server in the cluster direct access to a shared block device. They use a local storage area network (SAN).

Comparison with network file systems
Like client/server file systems, shared storage file systems work on a set of servers that are all members of a cluster. Unlike NFS, however, no single server provides access to data or metadata to other members. Each member of the cluster has direct access to the same storage device (the shared storage). All cluster member nodes access the same set of files.
Concurrency

Cache coherency is key in a clustered file system to ensure data consistency and integrity. There must be a single version of all files in a cluster visible to all nodes within a cluster. The file system must prevent cluster members from updating the same storage block simultaneously and causing data corruption. In order to do that, shared storage file systems use a cluster-wide locking mechanism. This controls access to the storage as a method to prevent conflicts.

For example, before creating a new file or writing to a file opened on multiple servers, the file system component must obtain the correct lock.

The requirement of cluster file systems is to provide a highly available service like an Apache web server. Any member of the cluster can see a fully coherent view of the data stored in their shared disk file system. All updates are arbitrated correctly by the locking mechanisms.

Performance characteristics

Shared disk file systems do not always perform as well as local file systems running on the same system. This is due to the computational cost of the locking overhead. Shared disk file systems perform well with certain workloads where each node writes almost exclusively to its own set of files. These files are not shared with other nodes.

Alternatively, a set of files may be shared across nodes in an almost exclusively read-only manner. This results in a minimum of cross-node cache invalidation and can maximize performance.

Setting up a shared disk file system is complex. Tuning an application to perform well on a shared disk file system can be challenging.

1.9. Choosing between network and shared storage file systems
Copier lien

Choose between network and shared storage file systems based on availability, performance, and maintenance needs. Network file systems suit most situations, while shared storage file systems best serve high-availability, minimal-downtime requirements.

When choosing between network and shared storage file systems, consider the following points:

  • NFS-based network file systems are an extremely common and popular choice for environments that provide NFS servers.
  • Network file systems can be deployed by using very high-performance networking technologies like Infiniband or 10 Gigabit Ethernet. This means that you should not turn to shared storage file systems just to get raw bandwidth to your storage. If the speed of access is of prime importance, then use NFS to export a local file system like XFS.
  • Shared storage file systems are not easy to set up or to maintain. Deploy them only when you cannot provide your required availability with either local or network file systems.
  • A shared storage file system in a clustered environment helps reduce downtime. It eliminates unmounting and mounting steps during typical fail-over scenarios involving high-availability service relocation.

Use network file systems unless you have a specific use case for shared storage file systems. Use shared storage file systems primarily for deployments requiring high-availability services with minimum downtime and stringent service-level requirements.

1.10. Volume-managing file systems
Copier lien

Volume-managing file systems integrate the entire storage stack for the purposes of simplicity and improvements within the storage layers.

Available volume-managing file systems
  • Red Hat Enterprise Linux 10 provides the Stratis volume manager. Stratis uses XFS for the file system layer and integrates it with Logical Volume Manager (LVM), Device Mapper, and other components.

Stratis was first released in Red Hat Enterprise Linux 8.0. It is conceived to fill the gap created when Red Hat deprecated Btrfs. Stratis 1.0 is an intuitive, command line-based volume manager. It can perform significant storage management operations while hiding the complexity from the user:

  • Volume management
  • Pool creation
  • Thin storage pools
  • Snapshots
  • Automated read cache

Stratis offers powerful features, but currently lacks certain capabilities of other offerings that it might be compared to, such as Btrfs or ZFS. Most notably, it does not support checksums that can automatically fix errors.

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Legal Notice

Theme

© 2026 Red HatRetour au début