---
title: "Linux Filesystems: The Complete Comparison Guide — ext4 vs XFS vs Btrfs vs ZFS"
date: 2026-09-23
time: "22:00"
model: admin
category: knowhow
summary: "The features, benchmarks, practical commands, and selection criteria of Linux's four major filesystems (ext4, XFS, Btrfs, ZFS), with hands-on code"
tags: Linux,filesystem,ext4,XFS,Btrfs,ZFS,server,storage,format,backup
---

# Linux Filesystems: The Complete Comparison Guide — ext4 vs XFS vs Btrfs vs ZFS

"How should I format this?" The answer to that question changes completely with your purpose. ext4 is the king of stability, XFS the master of large-volume handling, Btrfs the wizard of snapshots, and ZFS the enterprise endgame.

## 1. What Is a Filesystem

A filesystem is the set of rules for storing and managing data on a disk. It is like a library's classification system. Even on the same hard disk, read/write speed, stability, and features differ completely depending on the filesystem.

## 2. Core Comparison of the Four Filesystems

| Feature | ext4 | XFS | Btrfs | ZFS |
|------|------|-----|-------|-----|
| Max volume size | 1 EB | 8 EB | 16 EB | 256 ZiB |
| Snapshot | Not supported (LVM needed) | Not supported (LVM needed) | Built-in (very fast) | Built-in (powerful) |
| Shrink | Possible | Not possible | Possible | Not possible |
| Compression | Not supported | Not supported | Built-in (zstd/lzo) | Built-in (lz4/zstd) |
| Built-in RAID | mdadm needed | mdadm needed | Btrfs RAID built-in | RAID-Z built-in |
| Memory use | Very low | Low | Moderate | High (RAM needed) |
| Data integrity | Basic | Basic | Basic (CoW) | Checksums, irreplaceable |
| Built into kernel | Yes | Yes | Yes | No (license) |
| Kernel introduction year | 1992 (ext) -> 2008 (ext4) | 1993 | 2009 | 2005 (Solaris) -> 2013 (Linux) |

## 3. ext4 — Linux's Longtime Standard

### Key Features

ext4 is a filesystem proven over more than 20 years. It has almost no bugs and ships as the default on every Linux distribution.

- **Journaling**: Writes to a journal before writing data, so recovery after an abnormal shutdown is fast
- **Extent-based allocation**: Groups contiguous blocks into a single extent, improving small-file handling speed
- **Delayed Allocation**: Buffers writes and allocates them all at once, reducing file fragmentation

### Practical Commands

```bash
# Format ext4
sudo mkfs.ext4 /dev/sdb1

# Mount (default options)
sudo mount /dev/sdb1 /mnt/data

# Tune mount options — read-heavy server
sudo mount -o noatime,nodiratime,data=writeback /dev/sdb1 /mnt/data

# Register permanently in fstab
echo '/dev/sdb1 /mnt/data ext4 defaults,noatime,nodiratime 0 2' | sudo tee -a /etc/fstab

# Check disk usage
df -hT /mnt/data

# Defragmentation (ext4 has no automatic defrag, so it must be manual)
sudo e4defrag /mnt/data

# Integrity check (online possible)
sudo e2fsck -f /dev/sdb1
```

### Best Practices

- Adding the `noatime` option in `/etc/fstab` skips unnecessary access-time recording and improves I/O performance
- `data=writeback` mode gives the fastest write performance but slightly increases the risk of data loss on an abnormal shutdown
- `data=ordered` (the default) has the best balance of stability and performance

## 4. XFS — The Master of Large-Volume Handling

### Key Features

XFS is a high-performance filesystem developed on IRIX, optimized for large databases like MySQL/PostgreSQL and for handling large media files.

- **Allocation Groups (AG)**: Divides the disk into independent regions to improve concurrent write performance
- **B+tree-based directories**: Maintains directory search speed even with millions of files
- **Realtime streaming**: Specialized for real-time I/O such as media streaming
- **Can grow but not shrink**: You can enlarge a volume but not reduce it

### Practical Commands

```bash
# Format XFS
sudo mkfs.xfs /dev/sdb1

# Mount
sudo mount /dev/sdb1 /mnt/data

# Mount options — for a DB server
sudo mount -o noatime,nodiratime,logbufs=8,logbsize=256k /dev/sdb1 /mnt/data

# Register in fstab
echo '/dev/sdb1 /mnt/data xfs defaults,noatime 0 2' | sudo tee -a /etc/fstab

# Check disk usage
df -hT /mnt/data
xfs_info /dev/sdb1

# Defragmentation
sudo xfs_fsr /mnt/data

# Repair tool
sudo xfs_repair /dev/sdb1

# Online repair (with it mounted)
sudo xfs_repair -L /dev/sdb1
```

### Best Practices

- The RHEL/CentOS/Fedora family defaults to XFS — keeping it as-is is the safest
- Combining PostgreSQL's `shared_buffers` with XFS's `noatime` maximizes DB performance
- When storing large log files, increasing the log buffer with `logbufs=8` improves write performance

## 5. Btrfs — The Wizard of Snapshots and Data Protection

### Key Features

Btrfs is based on Copy-on-Write (CoW) and supports snapshots, recovery, RAID, and real-time compression at the filesystem level. It is mainly adopted by Synology NAS and the like.

- **Copy-on-Write (CoW)**: When modifying data it writes to a new block without touching the existing one -> snapshots are created instantly
- **Real-time compression**: Compresses automatically when saving files (zstd, lzo, zlib) -> saves disk space
- **Btrfs RAID**: Supports RAID 0/1/5/6/10 at the filesystem level without mdadm
- **Subvolumes**: Can be managed like independent volumes within a single partition

### Practical Commands

```bash
# Format Btrfs (single, no RAID)
sudo mkfs.btrfs /dev/sdb1

# Format Btrfs (RAID 1 — mirroring)
sudo mkfs.btrfs -d raid1 -m raid1 /dev/sdb1 /dev/sdc1

# Mount
sudo mount /dev/sdb1 /mnt/data

# Register in fstab
echo '/dev/sdb1 /mnt/data btrfs defaults,noatime 0 2' | sudo tee -a /etc/fstab

# Create a subvolume
sudo btrfs subvolume create /mnt/data/@home
sudo btrfs subvolume create /mnt/data/@snapshots

# Create a snapshot (finishes in 1 second)
sudo btrfs subvolume snapshot /mnt/data/@home /mnt/data/@snapshots/home-$(date +%Y%m%d)

# List snapshots
sudo btrfs subvolume list /mnt/data

# Delete a snapshot
sudo btrfs subvolume delete /mnt/data/@snapshots/home-20260923

# Check real-time compression
sudo btrfs filesystem defragment -r -czstd /mnt/data

# Check disk usage (per subvolume)
sudo btrfs filesystem usage /mnt/data

# Integrity check
sudo btrfs scrub start /mnt/data
sudo btrfs scrub status /mnt/data
```

### Best Practices

- A snapshot is not a backup. If the hard disk physically fails, the snapshot dies with it -> always pair it with an external backup
- The `noatime` option, combined with CoW, greatly improves I/O performance
- zstd compression slightly increases CPU usage but saves 30-50% of disk space

## 6. ZFS — The Enterprise Endgame

### Key Features

ZFS is a filesystem with data integrity, powerful RAID, and large-scale caching built in. It is optimal for bundling several hard disks into safe, enormous storage.

- **Checksum-based integrity**: Computes a checksum for every block and automatically detects data corruption
- **Self-healing**: In a mirror/RAID-Z configuration, automatically recovers corrupted blocks from good ones
- **ARC (Adaptive Replacement Cache)**: Uses RAM as a disk cache to maximize repeated-read performance
- **ZFS on Linux**: Not built into the kernel due to licensing, so a separate install is needed

### Practical Commands

```bash
# Install ZFS (Ubuntu/Debian)
sudo apt install zfsutils-linux

# Create a ZFS pool (single disk)
sudo zpool create datapool /dev/sdb1

# Create a ZFS pool (RAID-Z1 — 1-disk parity)
sudo zpool create datapool raidz1 /dev/sdb1 /dev/sdc1 /dev/sdd1

# Create a ZFS pool (RAID-Z2 — 2-disk parity)
sudo zpool create datapool raidz2 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

# Check pool status
zpool status datapool

# Check pool usage
zpool list datapool
zfs list

# Create a snapshot
sudo zfs snapshot datapool/home@backup-20260923

# List snapshots
sudo zfs list -t snapshot

# Recover from a snapshot
sudo zfs rollback datapool/home@backup-20260923

# Automatic snapshots (zfs-auto-snapshot)
sudo apt install zfs-auto-snapshot
# Automatic hourly snapshots (keep up to 24)
sudo zfs set com.sun:auto-snapshot:hourly=true datapool/home

# ZFS pool online repair
sudo zpool scrub datapool

# Add a disk (online expansion)
sudo zpool add datapool /dev/sdf1
```

### Best Practices

- ZFS consumes a lot of RAM. At least 8GB, preferably 16GB or more, is recommended
- Monitoring the ARC cache hit rate with the `arcstat` command lets you identify disk I/O bottlenecks
- RAID-Z1 is only meaningful with 3 or more disks. With 2 disks, mirroring is safer

## 7. Performance Benchmark Comparison

A general performance comparison in the same NVMe SSD environment. Actual performance varies with hardware, workload, and options.

| Task | ext4 | XFS | Btrfs (compression OFF) | Btrfs (zstd) | ZFS (lz4) |
|------|------|-----|-----------------|-------------|-----------|
| Pure read (4K random) | Fast | Fast | Fast | Fast | Moderate (very fast on ARC hit) |
| Pure write (4K random) | Fast | Very fast | Moderate | Slow | Slow |
| Large streaming write | Fast | Very fast | Fast | Fast | Fast |
| Snapshot creation | — | — | Instant (under 0.1s) | Instant | Instant |
| File copy | Moderate | Moderate | Very fast (CoW) | Very fast | Moderate |
| Disk space utilization | Moderate | Moderate | Good (with compression) | Very good | Good (lz4) |

**Key point**: Btrfs's CoW creates only a pointer when copying a file, with no physical copy, so even a multi-GB file is copied instantly. zstd compression adds a little CPU load but saves 30-50% of disk space.

## 8. Practical Selection Guide

### Case 1: "I don't know, I just want the most stable" -> ext4

For a general web server, a light application server, or a personal Linux PC, choose ext4. Thanks to its decades of proven stability, it has the lowest chance of data corruption even when the system goes down unexpectedly.

```bash
# The safest basic setup
sudo mkfs.ext4 /dev/sdb1
sudo mount -o defaults,noatime,ordered /dev/sdb1 /mnt/data
```

### Case 2: "I deal with large databases or media files" -> XFS

For large DB servers such as MySQL/PostgreSQL, servers where log data accumulates in gigabytes, or handling video files, XFS is the answer.

```bash
# Optimal setup for a DB server
sudo mkfs.xfs /dev/sdb1
sudo mount -o noatime,logbufs=8,logbsize=256k /dev/sdb1 /var/lib/mysql
```

### Case 3: "Frequent backups and preventing data loss matter" -> Btrfs

For environments that create and delete virtual machines often, or that must back up the filesystem hourly for ransomware preparedness, Btrfs is useful.

```bash
# Optimal setup for NAS/backup
sudo mkfs.btrfs /dev/sdb1
sudo mount -o defaults,noatime,compress=zstd /dev/sdb1 /mnt/data
sudo btrfs subvolume create /mnt/data/@data
sudo btrfs subvolume create /mnt/data/@snapshots

# Automatic snapshot script (crontab)
echo '0 * * * * root btrfs subvolume snapshot /mnt/data/@data /mnt/data/@snapshots/data-$(date +\%Y\%m\%d\%H)' > /etc/cron.d/btrfs-snapshot
```

### Case 4: "A dozens-of-TB professional backup/storage server" -> ZFS

If you want to bundle several hard disks into safe, enormous storage, ZFS is recommended.

```bash
# Optimal setup for a storage server
sudo zpool create -o ashift=12 datapool raidz2 /dev/sd{b,c,d,e}
sudo zfs create -o compress=lz4 -o atime=off datapool/data
sudo zfs create -o compress=zstd datapool/backup
sudo zfs set com.sun:auto-snapshot:daily=true datapool/data
```

## 9. The 2026 Recommendation Formula

| Purpose | Recommended filesystem | Reason |
|----------|----------------|------|
| General Linux PC/web server | **ext4** | Proven stability, best compatibility |
| Large DB/media server | **XFS** | Optimized for large I/O |
| Backup/virtualization/NAS | **Btrfs** | CoW snapshots, real-time compression |
| Professional storage/enterprise | **ZFS** | Self-healing, RAID-Z, integrity |
| Docker/container host | **ext4** or **XFS** | Officially recommended by Docker |

**Final tip**: A filesystem is hard to change once formatted. Before adopting one, always understand your own workload (I/O pattern, data size, backup requirements) and then choose.