Learn Linux Filesystem - ZFS: Pools, Datasets & Snapshots

#Introduction

ZFS is the biggest leap in the history of Linux filesystems. ZFS isn't just a filesystem — it's also a volume manager, RAID controller, and checksum verifier combined into one. The consequence: you create a pool on top of raw disks, then create datasets inside it without worrying about partitions, MD RAID, or LVM separately.

This episode covers the pool and vdev architecture, the concept of datasets (filesystems and zvols), snapshots and clones, send/receive for replication, and scrub to maintain integrity. Note that ZFS snapshot concepts are nearly identical to btrfs from the previous episode, but the pool and dataset implementation is something btrfs doesn't have.

Before continuing, make sure OpenZFS is installed and its kernel module is loaded. Verify with zpool and zfs.

#Pools and Vdevs

#Pool Architecture

A pool is the collection of storage managed by ZFS. Inside the pool there are one or more vdevs (virtual devices). There are three types of vdev:

• Stripe (one disk or several disks without redundancy) — full capacity, no protection.
• Mirror — duplicate copies of data; one disk can be lost without data loss.
• RAIDZ (raidz1, raidz2, raidz3) — single, double, or triple parity.

Check existing pools:

zpool status
zpool list

zpool status is your main diagnostic gateway — from it you see pool health, vdev sizes, and checksum errors.

#Creating Your First Pool

Create a pool from two disks in mirror mode:

sudo zpool create -f labpool mirror /dev/loop0 /dev/loop1
zpool status labpool

-f forces even if the devices already contain data (use with care). Because ZFS writes its own structures across the whole disk, there is no partition or MD RAID underneath — devices are given raw to ZFS.

View the results with:

zpool list labpool
sudo zpool iostat -v labpool

#Datasets: Filesystems and Zvols

#ZFS Filesystem Datasets

A dataset is the logical unit inside a pool where files are stored. Each dataset can have its own mount point, compression, quota, and properties:

sudo zfs create labpool/data
sudo zfs set compression=lz4 labpool/data
sudo zfs set quota=500M labpool/data
zfs list -r labpool

zfs list -r shows all datasets in the pool hierarchy. Each dataset is an independent filesystem that can be mounted, snapshotted, and sent on its own.

#Zvol: A Block Device from ZFS

A zvol (volume) is a block-type dataset — it appears as a /dev/zvol/... device that can be used for swap, VM disks, or another filesystem on top:

sudo zfs create -V 10G labpool/disk-vm
ls -l /dev/zvol/labpool/disk-vm

zfs create -V creates a raw block volume. On top of it you can create another filesystem (for example ext4), or hand it directly to a hypervisor as a VM disk. This makes ZFS an extremely flexible storage layer.

#Snapshots and Clones

#Snapshots

ZFS snapshots are nearly instant thanks to COW:

sudo zfs snapshot labpool/data@sebelum-update
zfs list -t snapshot

Snapshot names follow the format pool/dataset@label. Snapshots can be rolled back:

sudo zfs rollback labpool/data@sebelum-update

Rollback returns the dataset to the snapshot's state, discarding all changes made after it.

#Clones

A clone is a snapshot that can be written as a new dataset — without copying data until it's actually changed (COW):

sudo zfs clone labpool/data@sebelum-update labpool/data-staging

Clones are useful for creating test environments or container images without physically duplicating storage.

#Send/Receive and Scrub

#Replication with zfs send

zfs send produces a stream of changes that can be piped to another pool, including a remote one:

sudo zfs send labpool/data@sebelum-update | ssh remote "sudo zfs receive backup/data"

zfs send only accepts snapshots (or the difference between two snapshots with -i for incremental). This stream is the foundation of ZFS backup and offsite replication, which we'll explore in episode 9.

#Scrub and Self-Healing

sudo zpool scrub labpool
zpool status labpool

During a scrub, ZFS reads all data, verifies checksums, and automatically repairs damaged blocks from mirror/parity vdevs — self-healing. The CKSUM column in zpool status shows blocks that failed verification. If the damage is permanent (bad sector), the REPAIR column will increase after scrub marks and replaces it.

#Conclusion

ZFS offers a combination no other kernel filesystem can imitate: pools as a volume manager, datasets as logical units, snapshots and clones as COW protection, and send/receive plus scrub as the foundation of replication and integrity. Its complexity is paid for in RAM for ARC (cache) and a deeper understanding of the architecture.

Key takeaways:

• Pools consist of vdevs: stripe, mirror, or RAIDZ with 1-3 parity.
• There are two dataset types: filesystem (mountable) and zvol (block device).
• ZFS snapshots are instant; clones are writable snapshots.
• zfs send/zfs receive handle replication between pools or remotes.
• Scrub verifies checksums and repairs data from healthy copies.
• ZFS replaces partitions, RAID, and LVM — give it raw disks.

In the next episode, episode 7, we cover mount, fstab, and options — how to attach all filesystems to the directory tree, the role of UUIDs, per-filesystem mount options, all the way to systemd-mount and automount. This is the bridge between creating filesystems and real daily operations.