Skip to content 
I compare XFS EXT4 on NVMe servers based on the latest benchmarks and real-world data, and show you when each file system has a measurable performance advantage. I’ll focus on throughput, latency, and real-world workloads so you can make the most of NVMe performance in your server.
Key points
To start off, I'll briefly summarize the key findings before diving into the details, benchmarks, and tuning.
- Random I/O: Both are very close to each other; EXT4 has slightly higher throughput, while XFS has more consistent latencies.
- Sequential: XFS often leads the way with large files, with EXT4 close behind, delivering solid performance.
- Metadata: EXT4 offers some minor advantages; XFS provides consistent response times.
- Applications: Neck-and-neck in the polls, with differences in the low single digits.
- Tuning: The kernel, scheduler, I/O depth, free space, and mount options make all the difference.
XFS and EXT4 on NVMe: Technical Overview
EXT4 is considered a proven Linux standard and delivers very reliable It serves as the baseline and is used as a reference in many comparisons. XFS is designed to handle large files, high levels of parallelism, and sequential data streams, and is very effective at maximizing NVMe throughput. On modern hardware, the performance gap is narrowing because both file systems have matured over the years and new kernel versions continue to optimize the NVMe stack. In everyday workloads, load profiles are often the deciding factor: many small, random accesses occur in rapid succession, while large sequential transfers tend to favor XFS. Decision-makers should therefore be familiar with their I/O profile and not rely solely on general Rankings look.
Random I/O on NVMe: Small Blocks, High Parallelism
For 4K and 8K accesses, both file systems deliver IOPS at a very similar Performance levels, often differing by only a few percentage points. In some benchmarks, EXT4 shows slightly higher average values for random writes, which may be noticeable in OLTP-like scenarios. XFS, on the other hand, excels with more consistent latencies and less jitter over longer runs, which facilitates predictable response times under mixed workloads. In production environments, caches, application logic, and network paths often mask these subtle differences. As a result, other tuning parameters—such as the buffer cache, WAL strategy, or I/O depth—take center stage (Source: 1, 4, 7).
Sequential Transfers: Moving Large Files Efficiently
With MB-sized blocks and long, sequential streams, XFS often comes out on top because its extent layout handles large files efficiently managed. Backup windows, archive jobs, and sequential checkpoints benefit noticeably from this, especially on PCIe 4.0/5.0 NVMe. EXT4 remains close behind and delivers very good transfer rates that are rarely a limiting factor in many setups. The longer the stream and the larger the file, the more clearly the advantage shifts toward XFS. My short article provides a supplementary overview Performance comparison with typical server workloads (Source: 4, 5, 9).
Metadata Operations: Many Small Files
Workloads involving many file operations place heavy demands on metadata paths and result in differences in locking and journaling. Light. In some tests, EXT4 has a slight edge when it comes to quickly creating and deleting many small files. XFS, on the other hand, maintains consistent latencies, making it well-suited for logs, caches, and build directories. Compared to alternative file systems, both demonstrate mature management and predictable response patterns. Anyone moving large numbers of small files should pay attention to the mount options and run practical tests over extended periods of time (Sources: 1, 7, 13).
Benchmark Overview by the Numbers
I'll summarize the following trends concisely so you can quickly identify typical patterns recognize. Random I/O with small blocks: Differences are generally minor, often in the range of ±3–5 % for IOPS. Sequential I/O with large blocks: XFS often leads, especially with long streams and large files. Metadata-heavy tests: a slight advantage for EXT4 in some cases; XFS delivers consistent latencies. In analytical scenarios, both file systems often utilize around 80–85 % of the theoretical NVMe performance, depending on the kernel, drivers, and controller firmware (Sources: 1, 3, 4, 5, 10).
| Scenario | Tendency | Typical Advantage | Note |
|---|---|---|---|
| Random I/O (4K/8K) | Very close | EXT4 offers slightly higher throughput | XFS often has lower latency |
| Sequential (≥1 MB) | XFS in the lead | Higher throughput for large files | Long streams amplify the effect |
| Metadata Operations | Neck and neck | EXT4 Is Sometimes Faster for Create/Delete Operations | XFS Performs Consistently Under Mixed Load |
| Databases (OLTP) | Very close | EXT4: Slightly Higher TPS | XFS provides more consistent response times |
| Analytics/Reporting | Close | XFS for Large Scans | Both use 80–85 % of the hardware |
Application-Specific Benchmarks: Databases and Mixed Workloads
In PostgreSQL or MySQL tests, I see a neck-and-neck race influenced by latency profiles, WAL strategies, and buffer cache settings lives. EXT4 sometimes delivers a slightly higher number of transactions per second under high concurrency. XFS excels with stable response times, which can smooth out tail latencies in critical APIs. The differences remain small enough that database tuning has a greater impact than simply switching file systems. Therefore, decision-makers should measure endurance tests typical for their workload and carefully monitor application metrics (Sources: 2, 3, 9).
Kernel Version, NVMe Models, and Their Impact
Newer Linux kernels in the 5.x and 6.x series reduce latency and improve throughput, which benefits both file systems on fast NVMe drives and alleviates bottlenecks in the I/O stack reduces. Enterprise SSDs with large DRAM caches and power-loss protection further mask these differences because the controller and firmware impose limits before the file system becomes a significant factor. Budget consumer NVMe drives show the range more clearly, but in everyday use they usually perform quite similarly. PCIe 4.0/5.0 increases the headroom, making the sequential advantages of XFS more apparent. Kernel updates, NVMe firmware, and up-to-date drivers therefore yield measurable benefits (Source: 1, 5, 10, 11).
Tuning for NVMe: Scheduler, I/O Depth, Free Space
I often start with a simple scheduler like none or mq-deadline and adjust the I/O depth for each workload to fill queues efficiently. Too high a depth causes latency spikes, while too low a depth wastes parallel resources. Allocating 15–20 % of free space reduces fragmentation and keeps allocations fast. For XFS, I look at the distribution across allocation groups because they significantly influence the file system’s parallelism; a good place to start is the XFS Allocation Groups. I measure every change using an A/B test to ensure that the effects remain traceable and that no negative changes slip through.
Make Strategic Use of Mount Options
Mount options affect journaling, commit intervals, and write paths, and can impact latency and throughput noticeable Adjust. EXT4 offers useful controls for journal mode and commit times, while XFS provides options for log buffers and inode parameters. I adjust these settings based on the load profile and document every change. If you want to dive deeper, you’ll find concise notes on useful parameters in the EXT4 Mount Options. It remains important to test every mount configuration with real-world workloads, not just with synthetic tests.
Hosting Best Practices: Choosing Based on Workload
For traditional web applications with CMS and online stores, EXT4 provides a reliable Base, because many small files and mixed I/O patterns dominate. Highly parallel databases perform very well on both file systems; I make my decision based on existing experience, monitoring setup, and backup strategy. Large sequential data streams during backups and archiving favor XFS, which streamlines transfer windows. Analytics workloads also benefit from XFS’s handling of large scans, while mixed profiles often show little difference. If you’re unsure, set up a staging system and measure performance under the most important daily workloads.
Test Strategy: Realistic and Measurable
I combine short peak tests with long endurance runs so that I can assess both maximum values and jitter and aging effects see. Instead of relying solely on synthetic tools, I use copies of production databases, typical log files, and real import/export jobs. I always run monitoring with iostat, perf, and application metrics so that I can clearly demonstrate correlations. I repeat the tests after kernel updates or firmware changes to detect regressions early. This reveals whether XFS or EXT4 provides the better balance of throughput, latency, and predictability in my own environment (Source: 1).
Journaling, Barriers, and Sync Semantics on NVMe
Journaling details play a role in determining latency spikes and recovery behavior. EXT4 uses by default data=ordered and writes metadata to the journal, while user data is persisted before the commit. If you need maximum write throughput while accepting a certain level of risk, you can data=writeback consider, although this makes replays after crashes more difficult. Newer versions of EXT4 support fast_commit, which bundles many small metadata transactions and reduces commit times. XFS maintains its own log (journal), whose logbsize and logbufs significantly affect parallelism and latency. On NVMe, Write Barriers Important: Without Power-Loss Protection (PLP), barriers should remain active to ensure that the controller firmware is not reordered. With PLP, you can selectively reduce barriers to speed up fsync()-intensive workloads—but always weigh this against the risk. For applications with strict durability requirements (e.g., databases), clean fsync() behavior is more important than a few percentage points of additional throughput.
TRIM/Discard and Long-Term Behavior of NVMe
Affect Flash Discard/Trim-Strategies for sustainable write performance. Inline discard on mount (discard/async_discard) reduces the controller's background workload but can cause latency spikes under heavy load. Periodic fstrim-Runs (e.g., weekly) help maintain more consistent performance in many production environments and decouple the release of unused blocks from the hot path. XFS efficiently processes discards in batches, while EXT4 offers discard=async A conservative approach. It is important to ensure that discard is properly propagated through all layers (dm-crypt, LVM, MD-RAID, hypervisor). If 15–20 % of reserve space is kept free over the long term, internal garbage collection is reduced—latency jitter decreases, and write performance remains more stable.
RAID, LVM, and Encryption: Balancing the Layers Properly
Before formatting, the block geometry should be compatible with RAID/LVM. For XFS, the correct choice of sunit/swidth (Allocation-Alignment) the efficiency of large sequential transfers; in EXT4, this is done by stride/stripe-width. If the alignment is correct, read-modify-write cycles in the RAID are minimized. LVM-Thin and snapshots are convenient, but they increase latency in write paths—this has a greater impact on random workloads than on pure scan operations. dm-crypt/LUKS It consumes CPU resources and can limit IOPS with small blocks; modern AES-NI/ARM-Crypto help, but tail latencies typically increase slightly. For encrypted volumes, it’s worth readjusting I/O depth and queue affinities and explicitly allowing discards, if security policies permit it.
CPU/NUMA, Interrupt Affinity, and io_uring: Fine-Tuning Latency
NVMe scales across multiple submission/completion queues; whoever NUMA location Note that this reduces cross-node hops. NVMe IRQs and the application's worker threads should run on the same NUMA node where the memory is allocated. In Linux, IRQ pinning and customized rps/xps-Settings to keep the data path local. Modern workloads benefit from io_uring (instead of the older AIO), which reduces syscalls and allows batch submission. In fio tests, this results in lower latencies at the same IOPS. Excessively high queue depths (iodepth) However, these values skew the latency distribution; it makes sense to use a series of tests (e.g., 1, 4, 16, 64) to identify the sweet spot for each workload.
Container and VM Environments: Unique Features in the Stack
For containers (overlayfs), XFS has long been the go-to choice because d_type was reliably available early on, and large layer sets were managed efficiently. Today, modern EXT4 deployments offer comparable stability; performance differences are minor and are driven more by overlayfs than by the file system itself. In VMs, the hypervisor’s Virtio/NVMe front ends and caching modes are the dominant factors: cache=none plus O_DIRECT in the guest reduces double buffering. The following are important: Discard Pass and uniform sector sizes (4K vs. 512e) to avoid write amplification. Snapshot-driven platforms (e.g., QCOW2, ZVOL) implement copy-on-write; the choice of file system in the guest remains relevant, but the host backend often imposes limits sooner than XFS/EXT4 itself.
Recovery, Consistency, and Maintenance Windows
Both file systems are considered robust, but the Maintenance Routes differ. EXT4 can be thoroughly checked using e2fsck; on very large volumes, this takes a noticeable amount of time if errors are found, but benefits from incremental improvements (Fast-Commit shortens the replay time for smaller transactions). XFS is on Online Consistency configured; deep scans are run using xfs_repair, which requires a lot of RAM in critical situations and can take a long time with very large file systems. For production systems, it's worth fsfreeze Before taking LVM/storage snapshots, to ensure application-consistent backups; databases should also trigger their own checkpoint/backup mechanisms. Organizations with SLAs that have short RTOs and RPOs should explicitly schedule recovery tests—this debunks myths and reveals realistic downtime windows.
Feature Aspects Beyond Raw Performance
Performance isn't everything. XFS offers Reflink-based copies and deduplication hooks, which save storage space and reduce copy times for VM images and large media collections. EXT4 stands out for its broad tool support and conservative defaults, which simplify rollouts. Quotas are available in both worlds; XFS stands out with Project-Quotas for directory-based quotas in large multitenant structures. Options such as noatime/relatime/lazytime significantly reduce the metadata write load. Anyone using per-directory or per-file encryption (fscrypt) should factor in the slight overhead associated with small random access operations and ensure they have sufficient CPU resources available.
Avoiding Measurement Errors: Common Pitfalls
Many supposed differences in FS are, in reality, Test artifacts. Data sets that are too small end up in the page cache and mask differences; data sets should be larger than the available RAM. A missing warm-up distorts random-write profiles on flash; similarly, concurrently running maintenance jobs (scrubs, rebuilds, fstrim) lead to outliers. In fio tests, it must be clear whether direct=1 It is used to determine whether fsync() phases are set realistically and whether read/write mixes run interleaved or in phases. Reproducible results require fixed CPU frequencies (no aggressive scaling governors), a constant background load, and clear isolation between testing and monitoring.
Practical Checklist: Here's How to Proceed
- Determine the workload profile: Block sizes, read/write ratio, latency budget, burst behavior.
- Clean up the stack: Check the kernel, NVMe firmware, and driver versions; verify IRQ affinity and NUMA.
- Align Layout: Set the RAID/LVM alignment (sunit/swidth or stride/stripe width) correctly.
- Test Mount Options: Barriers, commit intervals, noatime/relatime/lazytime; XFS log parameters.
- Calibrate I/O Depth: Balance latency and throughput; find the sweet spot for each application.
- Allow for extra space: 15–20 % reserve for consistent latencies and less fragmentation.
- Define a Discard Strategy: Inline vs. periodic fstrim, propagating through all layers.
- Backups & Recovery: Test fsfreeze and snapshot processes; verify downtime under realistic conditions.
- A/B measurements: Change only one variable; correlate the results with application metrics.
Summary: Decision-Making Guidance Without Myths
XFS and EXT4 deliver very high performance on NVMe; the differences are usually negligible moderate and depend heavily on the I/O profile. Random workloads with small blocks are closely matched, while long sequential streams tend to give XFS the edge. EXT4 delivers slightly higher throughput in some transactional patterns, while XFS offers consistent latencies during sustained workloads. The kernel version, NVMe models, scheduler, I/O depth, free space, and mount options often influence the results more than the choice of file system alone. Those who measure accurately and understand their own workloads can make an informed decision—without myths and with measurable Profit.
