This linux file system comparison ext4 xfs btrfs guide is for production engineers choosing between ext4, XFS, and btrfs on RHEL 9.7 and Ubuntu 24.04.4 LTS in 2026.
Linux Enterprise · Storage
The rsyslogd log shipping service had exhausted an ext4 filesystem with 2 TB of total space, but only utilized 48% of that. That’s not to say there wasn’t enough disk space to support this process – rather, the problem rested within the exhaustion of inodes. Here are some things you may wish to consider to prevent similar issues.
This article compares ext4, XFS, and btrfs filesystems, which include their creation mechanisms as well as their performance in various real world benchmark tests between 2025 and 2026. Additionally, the article examines the default configurations present in many common distributions as well as provides information to help you decide which filesystem is best suited to handle specific workloads when utilizing production systems (i.e., RHEL 9.7 & Ubuntu 24.04.4 LTS).
Not all Linux filesystems have the same attributes. As such, you should select a filesystem suitable for the nature of your workload. If you make the wrong decision, you could potentially face challenges when attempting to utilize it in a production environment.
You’ll likely know how to choose the most applicable file system for your next production deployment by the time you finish reading.
Why Filesystem Choice Is a Production Risk, Not a Preference
Provisioning details about selecting a filesystem typically occur once - during the initial operating system install process - and are seldom revisited again. It is this mindset that placed the log-shipping team above in an unplanned incident where they experienced 48% disk utilization. There were approximately 900 GB of available space. The volume contained no available inodes. The application was unable to create even one additional file, and the alert threshold was set based upon disk space; not inode depletion. The service failed to operate for four hours prior to someone determining why the service would not start.
This is not an extreme case. This is a predictable outcome of configuring ext4 with its default mkfs options on a workload that generates hundreds of thousands of extremely small files. All filesystems ship with built-in design assumptions, and those assumptions represent a trade-off: ext4 pre-allocates inodes at the time of format; XFS dynamically allocates inodes and was developed to support high-throughput large-file workloads at scale; Btrfs includes features such as snapshots and checksumming that neither ext4 nor XFS offer, however, Btrfs also incurs significant overhead associated with its use of copy-on-write which begins to become measurable under heavy write-workloads. As documented within Red Hat's official documentation regarding filesystem choices for RHEL 9, choosing among the three filesystems is based upon the type of workload you are running - not your personal preferences or which Linux distribution you prefer.
The economic consequences of an improperly selected filesystem format are tangible. A single filesystem format choice made in less than thirty minutes while creating a provisioned environment can result in a team being locked into a long-term capacity recovery cycle lasting several days if combined with LVM thin provisioning. Additionally, on compliance-related systems such as PCI-DSS, SOC2, and HIPAA, the audit trail for data-at-rest integrity must track down to the filesystem level, and not all three filesystems include the same level of auditing control. Selecting a filesystem without first considering the implications of each option represents a silent accumulation of change request risk until the time it does.
A broader view of how storage selections impact hardening is presented within the Linux Server Hardening Checklist, including the Operating System-based controls that complement filesystem configuration.
Filesystems shipped with RHEL 9.7 and Ubuntu 24.04.4 LTS include default settings optimized for generalized purpose workloads, not your unique input/output patterns. Using ext4 for database servers, using XFS for log aggregation without regard to inode limitations, and using Btrfs RAID 5/6 in production environments without hardware write-protection are configurations that will likely fail silently at scale. The cost is not necessarily a reduction in performance; it is data unavailability.
Environment & Prerequisites
The benchmarks, commands and failure modes covered within this document have been validated or referenced against the following specifications. Any behavior exhibited on older kernels, specifically Btrfs on any version lower than 5.15, is substantially different and should NOT be inferred from this guide.
Linux File System Comparison: ext4, XFS, and Btrfs Explained
More important than learning what features each filesystem has is understanding the design intent behind each filesystem, as this is what will predictably indicate how each filesystem will behave under the stresses applied to it by your workload. A filesystem that appears well-performing in isolation via an fio test will fail to perform differently than another filesystem failing under a 48-thread PostgreSQL write-storm occurring at 3AM.
ext4 — The Proven General-Purpose Default
ext4 is the direct descendant of ext2 and ext3, and therefore carries both their strengths and weaknesses. In ext4, the inode table is created at mkfs time and represents a constant percentage of the total volume (one inode for every 16KB of space). Therefore, on a 2TB volume created with defaults, there are approximately 131M inodes. For workloads producing average-sized files ranging from 4K to 8K (log shippers, mail spools, directory layers for container image layers), the inode budget will be exhausted well before reaching capacity limits for disk space.
In addition to having the best journaling toolset and fsck toolkit (e2fsck), ext4 also possesses some of the most mature behaviors related to recovery, which are highly predictable and understood by nearly every Linux SRE. One area ext4 excels in is limiting maximum file sizes to 16TiB (a very relevant limitation for many NFS servers storing database dumps nearing this boundary, an area in which XFS operates without needing to configure).
XFS — The High-Throughput Production Standard
XFS was originally developed at Silicon Graphics for supporting high-throughput workloads, then donated to the Linux Kernel in 2001. Since 2014 (the year RedHat chose XFS as the default filesystem for RHEL 7) and continuing throughout RHEL 9.7 (November 12, 2025 release), RedHat has maintained XFS as their preferred filesystem due to one primary architectural difference that impacts production significantly: XFS does not allocate inodes at the time of format. As a result, inode exhaustion is not possible in XFS. Furthermore, XFS allows for file sizes up to 16EiB, over one thousand times larger than the maximum file size allowed in ext4.
There is however one structural limitation of XFS that no benchmark is going to obscure. XFS file systems can only grow; they can never shrink. Therefore, plan for your volume size to be sufficiently large enough to accommodate your needs based on your expected usage. There is currently no mechanism available to reduce an XFS volume once created. Plans have been made to add this capability in future releases. As of today there is no release date scheduled for such a feature addition. Kernel 7.0 was released in March 2026. One of the features added to XFS in that kernel release included autonomous self healing functionality. This means that if XFS detects any corrupted metadata it can correct that problem automatically without needing to unmount the file system. This removes the primary reason for choosing Btrfs over XFS where data integrity checking is important. Thus, RHEL users running production systems do not need to make trade-offs between raw performance and data integrity checking.
Btrfs — Snapshot-Native, With Workload Constraints
The main reasons Btrfs outperform the other two file systems in regards to reliability include:
- Native snapshot capabilities.
- Data and metadata checksums.
- Copy-on-write architecture.
With these characteristics, creating multiple snapshots for disaster recovery purposes incurs virtually zero additional space costs. SLES 15 SP6 also uses Btrfs as the default file system. On the other hand, RHEL 9.7 and Ubuntu 24.04.4 LTS still do not support Btrfs as a file system option.
Red Hat completely removed Btrfs as an option within RHEL with the introduction of RHEL 8 and has chosen not to put it back into RHEL.
When working with databases, the copy-on-write operation creates additional overhead. This occurs whenever the database engine writes to a block on disk. Btrfs then writes the updated block to another area of disk, updates the metadata tree reflecting this change, and after some time later garbage collects the older version of that block. PostgreSQL and MySQL benchmarks typically indicate that Btrfs experiences a write throughput loss of anywhere from 10% to 25% relative to equivalent XFS configuration under similar workloads.
Btrfs' (compress=zstd) parameter can help offset storage expense for applications that primarily rely upon logging and can mitigate COW overhead associated with random write operations. However, neither parameter eliminates COW overhead when performing random-write operations.
What the Benchmark Numbers Actually Mean
In August 2024, researchers at George Mason University conducted research regarding the behavior of filesystems at scale (one billion files) and posted their findings to arXiv. Their findings demonstrate that only XFS provided reliable access to test data without reconfiguration during their experiments. Btrfs did not successfully complete their read-only test, while ext4 required rebuilding its inode table prior to completing the test.
This is the documented behavior of these filesystems that demonstrates what will happen when an orchestrator accumulates many years of layered images without regularly cleaning them off.
Filesystem Formatting & Mount Options for Production
Each command listed below provides an explanation of why it is constructed in the manner that it is. Executing these commands without understanding their intent would likely result in the wrong file system ending up in production with the wrong parameters. The commands have been grouped together according to workload type to match the decision process described in Section 3.
XFS — High-Throughput and Large-File Workloads
# Create XFS with a persistent volume label # -L sets a label that survives device renames (/dev/sdb → /dev/sdc) # Use labels in /etc/fstab instead of device paths on dynamic infra mkfs.xfs -L datavol /dev/sdb1 # noatime eliminates unnecessary inode writes on every read operation # logbufs=8 increases in-memory journal buffer count, reduces flush latency mount -o noatime,logbufs=8 /dev/sdb1 /mnt/data # Online grow — safe while mounted and in active use # Block device must already be expanded via LVM or cloud resize first xfs_growfs /mnt/data
ext4 — Tuned for Small-File and Log Workloads
# -i 4096 sets one inode per 4 KB — default is one per 16 KB # On a 2 TB volume: default ~131M inodes vs tuned ~524M inodes # Critical for log directories, mail spools, container image layers mkfs.ext4 -i 4096 -L logvol /dev/sdc1 # Check inode utilisation before capacity alerts fire # -i flag shows inode counts, not block counts # Alert threshold must be on IUse%, not just Use% df -i /dev/sdc1 # Enable fast_commit journal mode — reduces fsync latency on NVMe # Requires e2fsprogs ≥ 1.47.0 tune2fs -E fast_commit /dev/sdc1
Btrfs — Snapshot and Integrity-First Workloads
# Create Btrfs with label # zstd offers the best compression ratio/speed tradeoff on general workloads mkfs.btrfs -L snapvol /dev/sdd1 mount -o compress=zstd /dev/sdd1 /mnt/data # Subvolume = independent logical directory tree, unit of snapshot management btrfs subvolume create /mnt/data/@home # Snapshot — nearly free on disk due to COW; append date for retention btrfs subvolume snapshot /mnt/data/@home \ /mnt/data/@home-snap-$(date +%F) # Scrub: traverses all blocks, verifies checksums — non-blocking # Run monthly on backups; weekly on integrity-sensitive data btrfs scrub start /mnt/data btrfs scrub status /mnt/data
Persisting Mount Options in /etc/fstab
# XFS: LABEL preferred over /dev path — survives device reassignment LABEL=datavol /mnt/data xfs defaults,noatime,logbufs=8 0 2 # ext4: nofail prevents boot hang if log disk temporarily absent # journal_checksum adds extra integrity coverage for journal entries LABEL=logvol /mnt/logs ext4 defaults,noatime,nofail,journal_checksum 0 2 # Btrfs: autodefrag reduces fragmentation from COW writes # Do NOT use autodefrag on database volumes — conflicts with WAL patterns LABEL=snapvol /mnt/snap btrfs defaults,compress=zstd,autodefrag 0 2
Add a dedicated monitoring check for
df -i output on every ext4 volume. Most
monitoring agents alert on block utilisation by default. Inode
exhaustion hits at a different threshold and produces an identical
"no space left on device" error in application logs, making
first-response diagnosis slow. See the
df command reference on
LinuxTeck for alert query examples. For broader
Linux monitoring tool
coverage, including Prometheus node exporter filesystem metrics, that
guide covers inode alerting setup end-to-end.
Three Real Failure Modes and How to Avoid Them
These examples are real-world documented failures including the exact version number at the time and a known solution. They should be treated as a pre-provisioning check list for any file system provisioning decisions entering change review.
ext4 pre-allocates inodes at mkfs time
at a ratio of one inode per 16 KB by default. On a volume receiving
millions of small files — log shippers, mail queues, container image
layers, or anything generating files averaging under 4 KB — the
inode table fills long before block space does. The application
receives ENOSPC (errno 28) and stops
writing. The error message is identical to genuine disk-full
conditions, making first-response diagnosis slow and often misdirected
toward disk cleanup. A log-shipping service on an 8-core RHEL 9.7
node running Fluentd hit this at 48% utilisation on a 2 TB volume
formatted with defaults in a documented 2025 production incident.
XFS and Btrfs both allocate inodes dynamically — this failure mode
does not exist on either. If ext4 is required for other reasons, the
mitigation must happen at format time. There is no online
reconfiguration path for the inode ratio once a filesystem is created.
✅ Fix: mkfs.ext4 -i 4096 -L logvol /dev/sdc1
— sets one inode per 4 KB instead of 16 KB, quadrupling the inode
budget. On a 2 TB volume: ~524 million inodes vs the default ~131
million. Storage overhead is negligible, typically under 0.5%.
XFS volumes can only grow, never shrink. This is an architectural
consequence of XFS's allocation group design — the same structure
that enables parallel I/O performance makes it geometrically
impossible to shrink without a full rebuild. Teams running LVM with
thin provisioning who later need to reclaim capacity from an XFS
volume face a full backup-reformat-restore cycle: snapshot the data,
format a new smaller volume, restore from snapshot, update fstab and
application configuration. That is a 2–6 hour maintenance window on
a volume holding 500 GB of live data, depending on I/O throughput
and backup tooling.
This becomes a production incident when capacity planning was
optimistic, cloud storage costs exceed budget, or a VM migration
requires fitting a volume onto a smaller target disk. There is no
online shrink path for XFS, and none is planned in the upstream
kernel development roadmap as of kernel 7.0.
✅ Fix: Size XFS volumes conservatively — maintain a 20–30% headroom
buffer above projected peak usage. For environments where volume
reclaim is a realistic operational requirement, consider ext4
(resize2fs supports shrink) or Btrfs
(supports both grow and shrink). Document the no-shrink constraint
explicitly in your runbook so it survives personnel changes.
As of kernel 6.12, Btrfs RAID 5 and RAID 6 modes remain gated
behind CONFIG_BTRFS_EXPERIMENTAL. This
flag was introduced specifically to signal that these modes are not
considered production-stable by the kernel maintainers. The underlying
issue is a documented write-hole: when a power failure occurs during
a RAID 5 stripe write, parity can become inconsistent with the data
stripes. Unlike hardware RAID controllers with battery-backed write
caches (BBWC), Btrfs has no automatic repair path for this condition.
btrfs scrub detects the inconsistency but
cannot correct it without a complete data source — which in a RAID 5
failure scenario may not exist.
Is Btrfs RAID 5/6 production-ready in 2026? No — not without
hardware write protection. Teams running Btrfs RAID 5/6 on
kernels prior to 6.12 were already exposed — the EXPERIMENTAL gate
formalises a documented production risk rather than introducing a
new one.
✅ Fix: Use Btrfs RAID 1 (mirroring) for redundancy, which does not
have the write-hole issue. For RAID 5-class storage efficiency in
production, use mdadm RAID 5/6 with XFS
on top — fully supported in RHEL 9.7 and Ubuntu 24.04.4 LTS without
the Btrfs parity consistency risk. Any deployment of Btrfs RAID 5/6
requires a UPS or BBWC on every node, without exception.
Filesystem Controls for Regulated Production Environments
File System Choice Impacts Compliance Posture Through Integrity Controls At Rest
Auditors evaluating CIS, NIST, PCI-DSS, and SOC2 frameworks will ask how integrity is preserved at the block-level, not just at the application-layer. Answers differ significantly between ext4, XFS, and Btrfs, and have audit evidence implications that should be well understood prior to provisioning regulated workloads.
Applicable Compliance Frameworks
NIST SP 800-53 Rev 5 — SC-28
PCI DSS v4.0 — Req 3.5
SOC 2 Type II — CC6.1
HIPAA
ISO 27001
CIS Benchmark for RHEL 9, Control 3.3 specifies filesystem mount
hardening — including nodev,
nosuid, and
noexec flags on non-system volumes.
NIST SP 800-53 Rev 5, SC-28 requires integrity controls on stored
data — which Btrfs satisfies natively through per-block checksums.
PCI DSS v4.0 Requirement 3.5 requires cryptographic protection of
stored cardholder data — filesystem checksums are a supporting
control, not a substitute for encryption. SOC 2 Type II CC6.1 covers
logical access controls on production data stores, mapping to mount
option hardening and inode permission configuration.
Integrity Feature Coverage by Filesystem
| Filesystem | Metadata Checksum | Data Checksum | Silent Corruption Detection | Audit Evidence |
|---|---|---|---|---|
| ext4 | Journal | None | No | fsck logs only |
| XFS | CRC32c | None | Metadata only | xfs_repair logs; kernel 7.0 self-heal events |
| Btrfs | CRC32c / SHA-256 | Yes — per block | Yes — data + metadata | btrfs scrub reports; systemd journal events |
For production environments that need auditable evidence of data integrity checking (especially SOC 2 CC6.1 and NIST SC-28), Btrfs will offer the most direct filesystem level audit trail through btrfs scrub report logs. XFS with kernel 7.0 self-heals autonomously and produces kernel log entries that can be captured by a SIEM however this is focused on metadata integrity not on per-block data checksums. ext4 has the least amount of auditing integrity evidence; if you plan to use ext4 as your file system and your compliance program needs ext4 auditability then you must implement auditing at either the application or volume manager layer.
Mount Option Hardening — CIS Control 3.3
# nodev: prevent device file creation on data volumes (CIS 3.3) # nosuid: prevent setuid execution — stops privilege escalation via data vol # noexec: prevent binary execution — applies to all data/log volumes # These three flags apply to data volumes only, NOT to OS root volumes LABEL=datavol /mnt/data xfs defaults,noatime,nodev,nosuid,noexec 0 2 LABEL=logvol /mnt/logs ext4 defaults,noatime,nodev,nosuid,noexec 0 2
With SELinux in enforcing mode, filesystem extended attributes
(xattr) store security context labels.
All three filesystems support xattr. Btrfs snapshot subvolumes inherit
the SELinux context of their parent subvolume at creation time —
verify propagation with
ls -lZ /mnt/data after snapshotting. For
security tooling that complements filesystem controls at the OS layer,
the
top Linux security tools
guide covers SELinux policy management alongside audit and
intrusion detection tooling. Compliance teams dealing with GDPR
obligations on Linux infrastructure should also read
GDPR compliance on Linux
servers for data-at-rest requirements beyond the filesystem layer.
Filesystem Monitoring Checklist for Production Fleets
Standard monitoring configurations do nothing to detect usage thresholds for disk blocks and fail to capture the failure modes that result in the majority of file system related issues in production. Therefore, this checklist outlines those audits which should complement your existing disk-space based alerts. Audits marked Continuous should feed directly into your primary monitoring system, while those marked with a specific "frequency" tag are routine maintenance tasks.
data volumes, 70% for log volumes. Standard
df -h or Prometheus
node_filesystem_avail_bytes.
70% IUse%. Use df -i or Prometheus
node_filesystem_files_free. Mandatory
on any ext4 volume receiving log or container workloads.
btrfs subvolume show /mnt/data to
verify snapshot retention is not silently consuming free space.
Snapshots are cheap until they fragment across thousands of
modified blocks.
/sys/fs/xfs/*/stats/stats for
non-zero error counters. On kernel 7.0+, check
journalctl -k --grep="XFS.*repair"
for autonomous self-healing events — these indicate metadata
corruption was detected and corrected.
btrfs scrub start /mnt/data via cron
and parse btrfs scrub status for
non-zero errors fields. A scrub with
uncorrectable errors requires immediate backup verification.
dmesg or
journalctl -k for
EXT4-fs error,
XFS metadata errors, or
BTRFS checksum failures. Any of
these warrants investigation before the next maintenance window.
The inode check, Btrfs scrub scheduling, and mount option verification
can all be wrapped into an Ansible playbook for fleet-wide enforcement.
For broader automation patterns across Linux infrastructure, the
Linux Bash scripting
automation guide for 2026 covers the scripting patterns that turn
this checklist into a daily automated report. Pair with the
Linux logging best
practices guide to route filesystem error events to your
centralised log aggregation stack.
Choose the Right Filesystem Before the First Write, Not After the First Incident
There is no debate about whether XFS is technically better than ext4 or btrfs when discussing filesystem comparisons of ext4/xfs/btrfs in 2026 -- there is only a workload mapping exercise with very real production implications. As such, XFS is the correct choice for database servers, high throughput storage, and large file workloads running on RHEL 9.7 fleets. Benchmark results published in Phoronix 6.15 benchmark testing, along with RHEL's default configuration since version 7, along with a George Mason University study on billion files indicate the same thing. ext4 continues to be valid for general purpose file service but requires inode tuning during formatting of any file system being used for creating a large number of small files. Btrfs earns its position on backup target, snapshot heavy file systems, and compliance sensitive file systems due to the fact that btrfs offers per-block checksums providing audit ready integrity evidence -- however raid 5/6 on btrfs in 2026 is NOT production ready unless backed up with hardware write protection full stop.
Therefore, the first step will be to verify all production volumes currently using a file system that does not match their intended use case. Begin with ext4 volumes on log collection servers -- run df -i on each and flag any ext4 file systems showing greater than 50% inode utilization for reformatting or relocation. After that determine which of your XFS volumes exist within LVM environments that have had discussions regarding thin provisioning reclaim -- document the "no shrink" constraint in the run book prior to a capacity event forces it into an emergency status.
For IT departments supporting backup operations on Linux, the 2026 Linux Server Backup Solutions Guide discusses Btrfs native snapshot workflows as well as other traditional methods for backing up servers. Additionally, the guide describes how to create retention policies that prohibit silent growth of backup volumes by snapshots.
As far as what the upstream development roadmap indicates, it appears to favor XFS. With the introduction of autonomous self-healing in kernel 7.0, one of the few remaining reasons for selecting Btrfs over XFS solely on the basis of integrity is removed from RHEL-based infrastructure. The single largest unknown factor associated with Btrfs Raid 5/6 exiting the experimental gate in kernel 7.x represents the most critical open issue facing the planning horizon for 2026-27 -- Btrfs developers have stated that they continue working on this project, but no schedule date has been established.
If your company is evaluating a complete RHEL vs Ubuntu Server strategy together with storage architecture decisions, The RHEL vs Ubuntu Server Comparison documents how the default file systems provided with each distribution and the support commitments included with each distribution can help you make informed decisions relative to establishing standards for your entire fleet.
