Learn NAS - Filesystem: ZFS vs ext4/btrfs

#Introduction

With the NAS installed, the most important technical decision left is the filesystem. Episode 5 compares the three main candidates: ZFS, the standard on TrueNAS SCALE; ext4 with mdadm, commonly used on OpenMediaVault; and btrfs, which is growing in popularity as an alternative.

ZFS wins on data integrity and snapshot features, but has a larger RAM appetite. ext4 is the most stable and simple filesystem, while btrfs offers built-in copy-on-write and snapshots at a lower resource cost than ZFS.

By the end of this episode you'll be able to explain the fundamental differences among the three and pick the right filesystem for each workload.

#ZFS: Data Integrity and Full Features

#RAIDZ, Mirror, and Stripe

ZFS combines volume management and filesystem in a single layer. The basic topologies you can create:

Mirror: two disks hold identical data; fast rebuild, effective capacity of half.
RAIDZ1/2/3: striping with parity; survives one, two, or three disk failures.
Stripe: no redundancy, full capacity, not recommended for important data.

Create pools with different topologies

zpool create mirror mirror-a sda sdb
zpool create raidz2 raidz-a sdc sdd sde sdf

The zpool create mirror mirror-a sda sdb command creates a mirror pool, while zpool create raidz2 creates a pool with double parity.

#Copy-on-Write and Snapshots

ZFS writes data using a copy-on-write mechanism: old data isn't overwritten immediately; instead, new blocks are written first and then referenced atomically. This is the foundation of snapshots — point-in-time views of the data that are instant and cost almost nothing in storage.

Create a ZFS snapshot

zfs snapshot tank/data@sebelum-update
zfs list -t snapshot

The zfs snapshot tank/data@sebelum-update command creates an instant snapshot. The snapshot list can be viewed with zfs list -t snapshot.

#Checksums and Scrubbing

Every data block in ZFS has a checksum that is verified when read. If there's a mismatch, ZFS tries to repair the data from parity or the mirror. Scrubbing periodically checks the entire pool to detect hidden damage.

Run a scrub on the pool

zpool scrub tank
zpool status tank

The zpool scrub tank command starts a full scan. Use zpool status to view progress and verification results.

#Datasets and Zvols

On top of the pool, ZFS works with two entities: datasets for file storage (like directories with their own properties) and zvols for raw block storage (like virtual disks). Datasets can have separate quotas, compression, and snapshots; zvols are used for VMs, iSCSI, or swap. Both will be broken down further in episodes 6 and 11.

#The Alternative: ext4 with mdadm

#ext4's Strengths

ext4 is the most mature and stable filesystem in the Linux ecosystem. On OpenMediaVault, the common combination is ext4 on top of mdadm RAID. Its strengths: simple, resource-efficient, and supported everywhere. Its weaknesses: no data checksums, no built-in snapshots, and corruption repair relies on fsck.

Create RAID1 with mdadm

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 /dev/md0

The mdadm --create command builds a RAID1 array from two disks, then mkfs.ext4 formats it with ext4.

#When to Choose ext4

ext4 remains a legitimate choice for a simple NAS: limited hardware, minimal snapshot needs, or a team already comfortable with classic Linux tooling. Since it has no built-in snapshots, you'll need to rely on LVM backups, rsync, or other layer solutions for point-in-time protection.

#The Alternative: btrfs

#Copy-on-Write and Snapshots in btrfs

btrfs is Linux's copy-on-write filesystem that provides built-in snapshots, checksums, and RAID1/RAID5. It's lighter than ZFS but less mature for RAID5/6, which had problems on older kernels. It suits simple NAS setups or single-disk systems with snapshot needs.

Create a btrfs filesystem

mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc
mount /dev/sdb /mnt/data

The mkfs.btrfs -d raid1 -m raid1 command creates btrfs with mirrored metadata and data.

#btrfs Snapshots

btrfs snapshots are created through subvolumes, a concept slightly different from ZFS datasets. Here's an example of creating a subvolume snapshot:

Snapshot a btrfs subvolume

btrfs subvolume snapshot /mnt/data/@ /mnt/data/@snap-1
btrfs subvolume list /mnt/data

The btrfs subvolume snapshot command copies a subvolume copy-on-write. This pattern is enough for simple rollback needs without ZFS's full complexity.

#When to Choose Each

A practical guide for choosing a filesystem:

ZFS: important data, many users, needs snapshots, replication, and checksums. The TrueNAS SCALE standard.
ext4 + mdadm: stable and simple needs, limited hardware, or migration from an old system.
btrfs: light OMV-based NAS that wants snapshots and checksums without ZFS's complexity.
Single disk: single-disk ZFS is still worthwhile for checksums and snapshots; ext4 for maximum simplicity.

Warning

btrfs RAID5 and RAIDZ1 are both not the best choice for very large disks, because long rebuild times raise the risk of a second failure during rebuild. Consider RAIDZ2 or btrfs RAID1 instead.

#Closing

In this episode 5 you compared ZFS with ext4/mdadm and btrfs, understood ZFS's standout features like copy-on-write, snapshots, checksums, and scrubbing, and have a guide for choosing a filesystem based on your needs.

Key takeaways:

ZFS excels at data integrity: checksums, snapshots, and scrubbing.
Mirrors rebuild fast; RAIDZ2 is safer for large disks.
Copy-on-write makes snapshots instant and cheap.
ext4 with mdadm is a stable, resource-efficient choice.
btrfs offers snapshots without ZFS's full complexity.

In the next episode, episode 6, we'll build pools, datasets, and shares — from vdev concepts, dataset properties like compression and quotas, to zvols for block storage and creating SMB/NFS shares. It's time to fill the pool you've created.