Filesystems (EXT4, XFS, Btrfs)

Overview: Why Multiple Filesystems?

On Linux you can choose from several mature local filesystems. For general-purpose servers and desktops today, the most common are:

ext4 — conservative, stable default on many distros
XFS — scales well for large filesystems and high I/O workloads
Btrfs — modern “copy-on-write” filesystem with snapshots, checksums, subvolumes

They all store files and directories, but differ in:

Feature set (snapshots, checksums, quotas, etc.)
Performance characteristics
Suitability for different workloads and hardware
Management tools and complexity

This chapter focuses on what makes each of these three distinctive and how to choose and work with them at a basic administration level.

ext4

ext4 (“Fourth Extended Filesystem”) is the evolution of ext2 and ext3. It’s the “boring and reliable” choice, which is often desirable.

Key Characteristics

Journaled filesystem (metadata and optionally data)
Widely supported, used as a default by many distros
Good all-around performance for desktops and servers
Low complexity compared to more feature-rich filesystems

Features (high level):

Extents (store ranges of blocks instead of block lists)
Delayed allocation (helps reduce fragmentation)
Large filesystem support (up to multi‑TB/EB, depending on options)
Online filesystem growth (you can grow an ext4 filesystem while mounted, in many cases)
Simple, mature tooling

What ext4 does not natively provide:

Built-in snapshots
Built-in checksums for file data (metadata checksums exist)
Integrated RAID or multi-device management
Advanced copy-on-write (CoW) semantics

Creating and Checking ext4

Create a new ext4 filesystem:

mkfs.ext4 /dev/sdX1

Optionally label it:

mkfs.ext4 -L mydata /dev/sdX1

Check and repair:

fsck.ext4 /dev/sdX1
# or the generic:
fsck /dev/sdX1

Filesystem tuning (example: disable last access time updates to reduce writes):

tune2fs -o noatime /dev/sdX1

View basic information:

tune2fs -l /dev/sdX1

When ext4 Is a Good Choice

General-purpose desktops and laptops
Small to medium servers with straightforward storage needs
Systems where simplicity and predictability matter more than advanced features
Environments where every tool and OS must reliably understand the filesystem (e.g., dual-boot with older systems, rescue tools)

XFS

XFS is a high-performance, 64-bit journaling filesystem originally developed by SGI. It’s tuned for scalability and parallelism.

Many enterprise-focused distributions (e.g., RHEL) use XFS as their default filesystem for general use.

Key Characteristics

Journaled filesystem
Excellent performance for:

Large files
High throughput
Many parallel I/O operations

Designed to scale to very large filesystems and files
Optimized allocation strategies to reduce fragmentation

Limitations and caveats:

Historically, shrinking (reducing size) of XFS filesystems is not supported; you can grow, but not shrink.
Does not provide built-in snapshots or integrated RAID.
Lacks end-to-end data checksumming (though metadata integrity is protected).

Creating and Checking XFS

Create an XFS filesystem:

mkfs.xfs /dev/sdX1

Label (during creation):

mkfs.xfs -L mydata /dev/sdX1

Check and repair:

xfs_repair /dev/sdX1

You typically do not run xfs_repair on a mounted filesystem. It’s often run from a rescue environment or after the filesystem has been force-unmounted.

Get information about the filesystem:

xfs_info /mount/point

Growing XFS

XFS supports online growth when the underlying block device has been expanded (e.g., you extended an LVM logical volume).

Example:

Extend the block device (done with other tools, such as LVM).
Grow the filesystem:

   xfs_growfs /mount/point

The filesystem grows to use the extra space.

When XFS Is a Good Choice

Large filesystems (hundreds of GB to many TB)
Workloads with large files (e.g., databases, media storage, scientific data)
Servers with many concurrent I/O operations
Environments where you mostly grow storage rather than shrink it

Btrfs

Btrfs (“B-tree filesystem”) is a modern, copy-on-write filesystem designed to bring advanced features directly into the filesystem layer.

It is feature-rich and flexible but also more complex to understand and administer correctly.

Key Characteristics

Core ideas:

Copy-on-write (CoW) for data and metadata
Built-in support for:

Snapshots
Subvolumes
Checksums for data and metadata
Multi-device usage (RAID-like layouts)
Transparent compression

This allows advanced workflows without additional layers like LVM for many use cases.

Copy-on-Write and Checksums

With CoW:

When you modify a file, Btrfs writes the changes to new locations instead of overwriting in place.
This behavior enables:

Snapshots: new snapshots initially share disk blocks with the original data
Safer updates: old versions remain available until freed
Easier rollbacks

Btrfs calculates checksums (e.g., CRC32C) for data and metadata:

On read, it verifies the checksum.
With RAID configurations that provide redundancy, Btrfs can often detect and correct silent data corruption (“bit rot”) using other copies.

Subvolumes and Mounting

A Btrfs filesystem can contain multiple subvolumes. Conceptually:

A subvolume is like an independent filesystem tree inside the same overall Btrfs volume.
Each can be mounted separately with its own mount options.

Example creation:

# Create a Btrfs filesystem on a device
mkfs.btrfs -L mybtrfs /dev/sdX1
# Mount it
mount /dev/sdX1 /mnt
# Create subvolumes
btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home

You might then mount them separately:

mount -o subvol=@ /dev/sdX1 /         # root filesystem
mount -o subvol=@home /dev/sdX1 /home

Many modern Btrfs-based distros use this scheme by default for easier snapshotting and system rollbacks.

List subvolumes:

btrfs subvolume list /mnt

Snapshots

Snapshots in Btrfs are:

Lightweight (initially share blocks with the original data)
Instant to create
Read-only or read-write

Create a snapshot (read-only):

btrfs subvolume snapshot -r /mnt/@ /mnt/@_snap_before_upgrade

Create a read-write snapshot:

btrfs subvolume snapshot /mnt/@ /mnt/@_test

You can mount a snapshot as you would any other subvolume, enabling you to:

Examine or copy back old versions of files
Roll back system changes by switching the default subvolume at boot

Snapshot management strategy is often combined with package managers and bootloader entries, but that integration is handled by other tools and is beyond this chapter.

Transparent Compression

Btrfs allows on-the-fly compression, which can:

Save disk space
Improve performance for some workloads (less data read/written from disk)

Common algorithms: zstd, lzo, zlib.

Mount with compression (example):

mount -o compress=zstd /dev/sdX1 /mnt

You can check per-file compression using btrfs filesystem df and other tools.

Multi-Device and RAID

Btrfs can manage multiple devices directly, providing RAID-like functionality:

RAID0, RAID1, RAID10 (well established)
RAID5/6 (more complex, historically had issues; check current distro recommendations before using)

Add a device:

btrfs device add /dev/sdY1 /mnt

Change data/metadata profile (e.g., to RAID1 for redundancy):

btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt

Balance re-distributes data/metadata across devices according to the selected profile.

Because these features are powerful and potentially dangerous if misused, you should consult up-to-date documentation and understand the implications before configuring Btrfs RAID in production.

Scrubbing and Self-Healing

A scrub walks the filesystem, reading data and metadata, checking checksums, and trying to repair corrupted blocks using redundant copies when available.

Run a scrub:

btrfs scrub start -Bd /mnt

Options:

-B — run in the foreground (block)
-d — print progress

This is an important maintenance operation on Btrfs, especially when using multiple devices and relying on its data integrity features.

Creating and Checking Btrfs

Create:

mkfs.btrfs /dev/sdX1

Check:

The main check/repair tool is btrfs check, but it should be used cautiously and usually on an unmounted filesystem. It’s not commonly run like fsck.ext4; Btrfs is designed to self-heal using scrubs and RAID where possible.

Basic info:

btrfs filesystem df /mnt
btrfs filesystem usage /mnt

When Btrfs Is a Good Choice

Systems where snapshots and rollbacks are valuable:

Desktop distributions that integrate Btrfs snapshots with update tools
Developer machines where you experiment frequently

Data where integrity and detection of silent corruption are important
Systems that benefit from transparent compression
Flexible setups where you may want subvolumes instead of traditional partition/LVM splits

Btrfs is more complex than ext4, so it’s helpful to start with non-critical data or distributions that ship good defaults and tooling around it.

Comparing ext4, XFS, and Btrfs (High-Level)

This is not an exhaustive performance comparison, but a practical “feel” for when each is appropriate:

ext4

Strengths: Simplicity, maturity, broad support, good general performance.
Weaknesses: Lacks built-in snapshots, integrated RAID, and full data checksumming.
Typical use: General-purpose desktops/servers, root filesystems where advanced features are not needed.

XFS

Strengths: Excellent performance with large files and high concurrency, scales to very large filesystems.
Weaknesses: Cannot shrink, no native snapshots or integrated RAID, limited data integrity features vs Btrfs.
Typical use: High-performance servers, large data volumes, workloads like media, backups, or databases (if vendor supports it).

Btrfs

Strengths: Snapshots, subvolumes, CoW, data and metadata checksums, built-in multi-device support, compression.
Weaknesses: More complex to manage correctly, historically had rough edges (especially RAID5/6), tooling and best practices vary across distros.
Typical use: Systems benefiting from snapshots and rollbacks, integrity-focused storage, flexible single-pool setups.

Practical Tips for Choosing

In many real-world scenarios:

If you’re unsure and need reliability with minimal learning curve:

Use ext4.

If you know you’ll handle very large datasets and want high throughput:

Consider XFS, especially if your distribution favors it.

If you want snapshots, compression, and data integrity features and are comfortable learning a more complex tool:

Consider Btrfs (or a distro that uses Btrfs by default and integrates it well).

Regardless of the filesystem:

Test on non-critical data first.
Use up-to-date documentation for your distribution and tools.
Ensure you have a backup before making changes, especially when experimenting with advanced features like Btrfs subvolumes, RAID, or balances.

Comments

Please login to add a comment.

Don't have an account? Register now!

Filesystems (EXT4, XFS, Btrfs)

Overview: Why Multiple Filesystems?

ext4

Key Characteristics

Creating and Checking ext4

When ext4 Is a Good Choice

XFS

Key Characteristics

Creating and Checking XFS

Growing XFS

When XFS Is a Good Choice

Btrfs

Key Characteristics

Copy-on-Write and Checksums

Subvolumes and Mounting

Snapshots

Transparent Compression

Multi-Device and RAID

Scrubbing and Self-Healing

Creating and Checking Btrfs

When Btrfs Is a Good Choice

Comparing ext4, XFS, and Btrfs (High-Level)

Practical Tips for Choosing

Comments

Where to Move