Modern Linux File Systems: Ext4, XFS, Btrfs, OpenZFS, and F2FS Compared

Objective

Whether you are installing Linux for the first time, deploying a production server, or managing cloud infrastructure, one decision has a long-term effect on performance and reliability: which file system to use. Many people accept the installer default without a second thought. That works for a lot of situations, but system administrators know the file system shapes how data is stored, accessed, protected, and recovered. A database server benefits from different choices than a desktop PC. A virtualisation host has different storage needs than a media server. Cloud environments demand scalability that older file systems were never designed for.

This guide explains how Linux file systems work, compares the five you are most likely to meet (Ext4, XFS, Btrfs, OpenZFS, and F2FS), shows which distributions use which by default, and gives you a practical way to choose. It also flags the places where the right answer is not obvious, so you do not learn about a limitation after the data is already on the disk.

What Is a Linux File System?

A file system is the method Linux uses to organise and manage data on a storage device. It determines how files are stored, named, retrieved, updated, and deleted. Without one, a hard drive or SSD is just a collection of storage blocks. The file system adds structure: directories, permissions, ownership, and metadata that let the operating system find things quickly.

Think of it as the catalogue in a large library. Thousands of books may sit on the shelves, but without a catalogue, finding a specific title would be slow and confusing.

A modern Linux file system is responsible for:

• Storing files and directories
• Tracking ownership and permissions
• Allocating and freeing disk space
• Protecting data integrity
  • Journaling or copy-on-write designs help the system recover cleanly after a crash or power loss
• Supporting large volumes and large files
• Managing metadata efficiently
• Delivering good read and write performance

Disks, Partitions, and File Systems

Beginners often mix these three up. They work together but are different things:

Layer	What It Is	Example
Disk	The physical or virtual storage device	/dev/sda, /dev/nvme0n1
Partition	A logical section of a disk. One disk can hold several.	/dev/sda1, /dev/sda2
File system	The structure created on a partition that organises the data inside it	Ext4, XFS, Btrfs

Disk (/dev/sda)
├── /dev/sda1   Ext4    mounted at /
├── /dev/sda2   XFS     mounted at /srv/appdata
└── /dev/sda3   Btrfs   mounted at /backup

Each partition can use a different file system depending on its purpose. That flexibility lets administrators tune different workloads on the same machine.

Why Modern File Systems Matter

Storage has changed a lot in a decade. Spinning disks have largely given way to SSDs and NVMe, and businesses now run containers, virtual machines, and very large databases. These workloads ask more of a file system than simply holding files. Modern designs aim to provide:

• Faster input and output
• Better scalability
• Journaling for quick crash recovery
• Snapshots
  • Point-in-time copies you can roll back to after a bad change
• Data integrity checks through checksums
• Compression
• Support for very large storage arrays
• SSD-aware optimisation

How We Got Here: Ext2, Ext3, and Ext4

File System	Key Improvement	Main Limitation	Today
Ext2	Larger partitions and better performance than older UNIX file systems	No journaling. After a crash, a full fsck check could take a long time on large disks.	Occasionally used on simple embedded or flash-based devices. Rarely recommended for general use.
Ext3	Added journaling: pending changes are recorded before being committed, so recovery after a crash is fast. Backward compatible with Ext2.	Limited by the size and efficiency constraints of its era	Largely replaced by Ext4
Ext4	Better performance, faster allocation, support for very large files and volumes, less fragmentation, improved journaling	No native snapshots, compression, or checksummed data	The long-standing general-purpose default on many distributions

The Five Modern File Systems at a Glance

Feature	Ext4	XFS	Btrfs	OpenZFS	F2FS
Design focus	Stable all-rounder	Scale and throughput	Flexible, feature-rich	Data integrity	Flash storage
Journaling or copy-on-write	Journaling	Journaling (metadata)	Copy-on-write	Copy-on-write	Log-structured
Native snapshots	No	No	Yes	Yes	No
Data checksums	Metadata only	Metadata only	Yes	Yes	Limited
Built-in compression	No	No	Yes	Yes	Yes
Can grow while mounted	Yes	Yes	Yes	Yes (add devices to the pool)	Limited
Can shrink	Yes, while unmounted	No	Yes, while mounted	Pools generally cannot be shrunk	Limited
In the mainline Linux kernel	Yes	Yes	Yes	No (separate module)	Yes

Ext4: The Reliable All-Rounder

If you have installed Ubuntu or Debian, you have very likely used Ext4 without noticing. It earned its reputation by being fast, stable, and dependable. Instead of chasing every new storage feature, it does the basics exceptionally well. For many administrators it is the set-it-and-forget-it choice: once configured, it needs very little attention and performs consistently across a wide range of workloads.

• Strengths:
  • Journaling for fast crash recovery
  • Excellent read and write performance for general workloads
  • Supports very large files and volumes
  • Reduced fragmentation and delayed allocation for efficiency
  • Mature, well-tested, and supported by virtually every distribution
• Limitations:
  • No native snapshots
  • No built-in compression
  • No automatic verification of file data (it checksums metadata, not your files)
  • No self-healing
• Best for: desktops, laptops, development machines, web servers, and small to medium general-purpose servers

XFS: Built for Performance and Scale

Where Ext4 aims to be a dependable all-rounder, XFS is designed for throughput and scalability. It was originally developed by Silicon Graphics (SGI) and has become one of the most trusted file systems in enterprise Linux. It is the default on Red Hat Enterprise Linux, Rocky Linux, and AlmaLinux. XFS performs especially well with large files and workloads that generate continuous disk activity, such as database servers, virtual machine hosts, and video storage.

• Strengths:
  • High-performance journaling and fast metadata handling
  • Excellent scalability and efficient handling of large files
  • Parallel input and output across many threads
  • Can be grown while mounted
• Limitations:
  • Cannot be shrunk after creation. If you need a smaller XFS volume, you back up, recreate, and restore.
  • No native snapshots. On RHEL, snapshots are usually handled one layer down with LVM.
  • Repair uses xfs_repair, not fsck
• Best for: enterprise servers, database servers, virtual machine storage, large backup repositories, video editing servers, and high-performance computing

These limits rarely hurt in enterprise settings, because storage is normally planned in advance and growth, not shrinkage, is the common requirement.

# Show details of a mounted XFS file system
xfs_info /srv/appdata

# Grow an XFS file system after extending the underlying logical volume
lvextend -L +10G /dev/vg_data/lv_app
xfs_growfs /srv/appdata

# Repair an XFS file system (it must be unmounted first)
umount /srv/appdata
xfs_repair /dev/vg_data/lv_app

Btrfs: The Feature-Rich Modern File System

Pronounced "Butter FS," Btrfs was created to address limitations in traditional Linux file systems. Instead of just storing files, it actively manages and protects them, and it builds in features that previously needed separate tools. It uses a copy-on-write design, meaning changed data is written to a new location instead of overwriting the old one, which makes cheap, instant snapshots possible.

• Strengths:
  • Instant snapshots and subvolumes
  • Built-in compression that saves space
  • Data and metadata checksums that detect silent corruption
  • Online resizing, including shrinking
  • Multiple-device support
  • Send and receive for efficient incremental backups
• Limitations:
  • More concepts to learn than Ext4 or XFS
  • Write-heavy workloads such as busy databases may need careful tuning
  • Not supported on Red Hat Enterprise Linux and its rebuilds. It is the default on Fedora Workstation and on openSUSE for the root file system.
• Best for: desktops, development and test environments, backup servers, home NAS devices, and anyone who wants easy rollbacks

The practical selling point is snapshots. Before a risky update you take a snapshot, and if something breaks you roll back instead of reinstalling.

# Take a read-only snapshot before a risky change
mkdir -p /data/.snapshots
btrfs subvolume snapshot -r /data /data/.snapshots/before-update

# List subvolumes and snapshots
btrfs subvolume list /data

# Check how the space is being used
btrfs filesystem usage /data

# Verify all data against its checksums
btrfs scrub start /data
btrfs scrub status /data

OpenZFS: Enterprise-Level Data Protection

When data integrity is the top priority, OpenZFS is one of the most advanced options available. It combines a file system and a volume manager in one system, managing storage pools, checking data for corruption, and simplifying administration. Every block is checksummed, and when redundancy exists, ZFS can repair bad data automatically, which is the self-healing behaviour people mean when they talk about it.

• Strengths:
  • End-to-end data integrity with self-healing on redundant pools
  • Powerful snapshots and replication
  • Built-in RAID-style redundancy and storage pooling
  • Compression, with optional deduplication
    • Deduplication is very memory hungry and is usually left off unless you have a clear reason
• Limitations:
  • More memory-intensive and more complex to plan than Ext4 or XFS
  • Not part of the mainline Linux kernel because of a licensing incompatibility, so it is installed as a separate module. Some distributions, Ubuntu among them, package it for you.
  • Often unnecessary for a simple desktop
• Best for: storage servers, backup appliances, NAS systems, virtualisation storage, and long-term archives where losing data is not acceptable

# Create a mirrored pool from two disks (this erases both disks)
zpool create tank mirror /dev/sdb /dev/sdc

# Create a dataset and enable compression
zfs create tank/data
zfs set compression=lz4 tank/data

# Take a snapshot and list snapshots
zfs snapshot tank/data@before-upgrade
zfs list -t snapshot

# Check pool health and run an integrity scrub
zpool status tank
zpool scrub tank

F2FS: Optimised for Flash Storage

As SSDs, NVMe drives, and phones became common, developers recognised that file systems built around spinning disks were not ideal for flash memory. F2FS (Flash-Friendly File System), created by Samsung, is designed around how flash actually behaves. It reduces unnecessary writes, which helps both performance and the lifespan of the device.

• Strengths:
  • Designed specifically for flash memory
  • Efficient write management and lower write amplification
  • Strong random write performance
  • Used by many Android devices
• Limitations:
  • More specialised than Ext4 or XFS
  • Smaller feature set and less common in traditional enterprise storage
  • Ext4 also performs very well on modern SSDs, so the gain depends on the device and workload
• Best for: SSD and NVMe laptops where you want flash-tuned behaviour, embedded Linux devices, Raspberry Pi projects, and IoT systems

What Each Major Distribution Uses by Default

This is the practical question behind most file system decisions: what will I get if I just click Next?

Distribution	Default File System	Notes
Ubuntu	Ext4	OpenZFS is available as an installer option on desktop releases
Debian	Ext4	Other file systems are selectable during installation
RHEL, Rocky Linux, AlmaLinux	XFS	Ext4 is supported. Btrfs is not.
Fedora Workstation	Btrfs	Fedora Server uses XFS
openSUSE	Btrfs for root	Snapshots are integrated with system updates

Which File System Should You Choose?

There is no single best file system. The right answer depends on your workload, your distribution, and how much complexity you are willing to manage.

Your Situation	Good Choice	Why
Everyday desktop or laptop	Ext4 (or Btrfs if you want rollbacks)	Stable and simple. Btrfs adds easy snapshots.
Enterprise server, databases, large files	XFS	Built for throughput and scale, and the RHEL default
Backup server or home NAS	Btrfs or OpenZFS	Snapshots, checksums, and efficient backups
Storage where data loss is unacceptable	OpenZFS	End-to-end integrity checking and self-healing
Virtualisation storage	XFS or OpenZFS	XFS for plain performance. OpenZFS where snapshots and replication matter.
Embedded, IoT, or flash-focused devices	F2FS	Designed around flash memory behaviour
Studying for RHCSA	XFS first, then Ext4	These are what the exam environment is built around

Essential File System Commands

Command	Purpose
lsblk	Display disks and partitions
df -h	Show disk space usage per file system
du -sh	Check the size of a directory
blkid	Show UUIDs and file system types
findmnt	Show mounted file systems as a tree
mount / umount	Mount and unmount a file system
mkfs.ext4 / mkfs.xfs	Create an Ext4 or XFS file system (this erases the target)
fsck / e2fsck	Check and repair Ext4 on an unmounted file system
xfs_repair	Check and repair XFS on an unmounted file system
xfs_info	Display XFS file system details
xfs_growfs / resize2fs	Grow an XFS or Ext4 file system to fill its device
tune2fs	View and adjust Ext4 parameters such as labels

A Complete Example: Create, Mount, and Persist a File System

This is the sequence you will repeat many times as an administrator. The device name here is a placeholder, and mkfs destroys whatever is on the target, so always confirm the device with lsblk first.

# 1. Identify the correct device before touching it
lsblk

# 2. Create an XFS file system on the partition (erases its contents)
mkfs.xfs /dev/sdb1

# 3. Create a mount point and mount it
mkdir -p /srv/appdata
mount /dev/sdb1 /srv/appdata

# 4. Get the UUID so the mount survives device name changes
blkid /dev/sdb1

# 5. Add an entry to /etc/fstab using the UUID
# UUID=1234abcd-12ab-34cd-56ef-1234567890ab  /srv/appdata  xfs  defaults  0 0

# 6. Test the fstab entry BEFORE rebooting
umount /srv/appdata
mount -a
findmnt /srv/appdata
df -hT /srv/appdata

The test in step 6 matters. A typo in /etc/fstab can leave a system unable to boot normally, and finding that out at 2am after a reboot is a bad way to learn it.

Best Practices

• Choose by workload, not popularity. The most talked-about file system is not automatically the right one for your server.
• Monitor disk usage regularly with df -h and du -sh.
  • Copy-on-write file systems such as Btrfs and OpenZFS also use space for snapshots, so check those separately
• Keep tested backups. A snapshot on the same disk is not a backup. If the disk fails, both are gone.
• Use UUIDs in /etc/fstab so mounts do not break when device names change.
• Use the right repair tool for the file system. fsck for Ext4, xfs_repair for XFS, btrfs scrub and btrfs check for Btrfs, zpool scrub for OpenZFS.
• Keep the system updated to benefit from file system performance and security fixes.

Common Mistakes to Avoid

• Using one file system for every workload. A mixed layout is often the better design.
• Skipping backups before disk changes. Partitioning and formatting are not reversible.
• Filling a disk to 100%. Performance drops and some file systems behave badly when nearly full. Copy-on-write designs are especially sensitive.
• Editing /etc/fstab without testing it. Always run mount -a or findmnt --verify before rebooting.
• Running a repair on a mounted file system. Unmount first. Running fsck on a mounted file system can cause damage.
• Running fsck on XFS and expecting it to repair anything. The fsck.xfs helper does nothing useful. Use xfs_repair.
• Planning to shrink an XFS volume later. You cannot. Size it with growth in mind, or be ready to rebuild.

Frequently Asked Questions

• Which Linux file system is best for beginners?
  • Ext4. It is stable, well documented, and supported almost everywhere. If you are on a Red Hat family distribution, you will get XFS by default, and that is also a perfectly good choice.
• Is XFS better than Ext4?
  • It depends on the workload. XFS tends to do better with large files and heavy parallel activity. Ext4 is a strong general-purpose choice and is the only one of the two that can be shrunk.
• Why is Btrfs getting more popular?
  • Snapshots, compression, and checksums are built in, which makes it attractive for desktops, backups, and development machines. Its adoption as a default on Fedora Workstation and openSUSE has also helped.
• Which file system is best for SSDs?
  • F2FS is designed for flash storage, but Ext4 and XFS also perform very well on modern SSDs and NVMe drives. For most people the difference is small, so pick based on features you need rather than SSD tuning alone.
• Can I change a file system without losing data?
  • Usually no. Changing a file system normally means backing up, reformatting, and restoring. There are conversion tools in narrow cases, such as converting Ext4 to Btrfs in place, but even then you should take a full backup first.
• File Systems and Linux Certifications
  • File system management is part of both major Linux certifications. The RHCSA expects you to create, mount, and use XFS and Ext4 file systems and to make mounts persistent. LFCS covers similar ground across distributions. In practice that means being comfortable with mkfs, mount, blkid, /etc/fstab with UUIDs, and growing file systems after extending storage. The exam environment checks that your configuration survives a reboot, so always test persistence before you finish.

Conclusion

Modern Linux file systems are designed for different storage needs, from personal desktops to enterprise data centres. Understanding what each does well, and where each falls short, lets you make decisions you will not regret later.

• Ext4 is the dependable default for everyday use on Ubuntu and Debian
• XFS is the scalable, high-throughput default on RHEL, Rocky Linux, and AlmaLinux. It can grow but cannot shrink.
• Btrfs adds snapshots, compression, and checksums. It is the default on Fedora Workstation and openSUSE, but is not supported on RHEL.
• OpenZFS prioritises data integrity and self-healing. It is powerful but heavier, and it ships outside the mainline kernel.
• F2FS is tuned for flash storage and is common in embedded and mobile devices
• Use the right repair tool for each, use UUIDs in /etc/fstab, and test every mount before you reboot

Whether you are learning Linux, running production servers, or preparing for a certification, knowing when and where to use each file system is an essential skill. Start with the one that matches your distribution and workload, learn its tools well, and add the more advanced options when you have a concrete reason to.