Tooling

Filesystems

ZFS, btrfs, XFS, ext4 — picking a filesystem in 2026.

The candidates

  • ext4 — boring default; works everywhere; reasonable speed; no fancy features.
  • ZFS (OpenZFS) — copy-on-write; snapshots; checksums; send/receive replication; pools across many disks. The default for "I care about my data."
  • btrfs — copy-on-write; snapshots; subvolumes; native to recent Linux. Stable for single-disk and RAID-1; RAID-5/6 still has issues.
  • XFS — fast for big files; the default on Red Hat / CentOS Stream / Rocky / Alma.
  • f2fs — flash-optimized; common on Android.
  • bcachefs — newer copy-on-write FS; in mainline Linux 6.7+; promising but not yet ZFS-stable.
  • NTFS / exFAT / APFS — non-Linux; you'll touch them when interfacing with other OSes.

When to pick what

  • Cloud / VM root disks: ext4 or XFS. Boring is right.
  • Bulk storage / NAS: ZFS. Snapshots + integrity checking are worth it.
  • Single-disk laptop with snapshots: btrfs (or ZFS if you've installed the modules).
  • Database hosts: XFS for many DBs (Postgres / MySQL); some prefer ext4. Don't run on btrfs.
  • Container hosts: ext4 or XFS for the Docker dir; CoW issues plus btrfs is a pain combo.
  • NVMe / mobile / phones: f2fs.

ZFS-specific

  • Pools and datasets — pool is the storage; datasets are mountable subdivisions.
  • Compression on by defaultzstd is free space.
  • Snapshotszfs snapshot pool/data@daily-2026-05-09. Cheap and instant.
  • zfs send | zfs receive — replicate datasets between hosts; encrypted backup over SSH.
  • ARC sizing — ZFS uses memory aggressively. Limit zfs_arc_max on hosts that run other things.
  • Avoid mixing disk sizes in vdevs.
  • RAID-Z2 minimum for important data; mirrors for performance.
  • Scrubs — schedule monthly; zpool scrub checks integrity.

btrfs-specific

  • Subvolumes are like cheap separate filesystems.
  • Snapshots are instant.
  • btrfs send | btrfs receive — same idea as ZFS.
  • Avoid btrfs RAID 5/6 in production. Use RAID-1 / RAID-10 or use mdadm + ext4/XFS underneath.
  • Scrub regularlybtrfs scrub start /mnt/data.

Snapshots are not backups

  • ZFS / btrfs snapshots protect against fat-finger / ransomware on the same pool.
  • Only off-host replication (send/receive to a different machine) protects against the host dying.
  • See Backup.

Networked / shared filesystems

  • NFS — boring, works.
  • SMB / CIFS — Windows-friendly.
  • CephFS / GlusterFS — distributed; see Distributed Storage.
  • JuiceFS — POSIX over S3.
  • SeaweedFS — distributed file + S3 layer.

Patterns to adopt

  • ZFS for any system whose data matters. The integrity story is unique.
  • Compression on. zstd: free perf + space.
  • Schedule scrubs. Monthly is fine for HDDs; weekly for SSDs.
  • Atomic snapshots before risky changes (zfs snapshot + apt upgrade).
  • Don't run DB-heavy workloads on btrfs. Postgres + btrfs has well-documented gotchas; XFS/ext4 is preferred.

Pick this if…

  • Default Linux server: ext4 (cloud / VM) or XFS (Red Hat ecosystems).
  • Care about data integrity / want snapshots / replication: ZFS.
  • Laptop with desktop snapshots: btrfs.
  • Database host: XFS (or ext4); avoid btrfs.
  • NAS / homelab / TrueNAS: ZFS.
  • Mobile / flash-only: f2fs.

On this page