Learn Linux Filesystem - btrfs: Subvolumes, Snapshots & COW

#Introduction

Now we enter the modern generation: btrfs — the Linux kernel's built-in Copy-on-Write (COW) filesystem. Unlike ext4 and XFS, which write in place with a journal, btrfs writes new data to new blocks and changes pointers atomically. The consequences are significant: instant snapshots, fast rollbacks, checksums on all data, and transparent compression.

btrfs's strength isn't a single feature, but a combination: subvolumes to organize data, snapshots for protection, send/receive for replication, and balance for managing block allocation. In this episode we'll cover the concepts, then practice all of them in the lab.

Before continuing, make sure the btrfs-progs toolchain is installed and the loopback disk is available. The btrfs command is the main gateway to all btrfs operations.

#btrfs Core Concepts

#Copy-on-Write and Checksums

When a file is modified, btrfs doesn't overwrite the old block. New data is written to new blocks, then the metadata is updated to point to the new blocks. The old blocks remain until nothing references them — this is the foundation of snapshots. Every data block also stores a checksum (CRC32C by default, or xxhash). When read, the checksum is verified; if it fails, btrfs tries to recover from another copy (if one exists) or reports an error.

#Subvolumes and Snapshots

A subvolume is a part of the filesystem with its own namespace, like a top-level directory that can be mounted independently. A snapshot is a copy-on-write of a subvolume — creating one is nearly instant because no data is copied, only pointers to the same blocks.

An important difference: btrfs snapshots can be read-write or read-only. Read-only snapshots are used as restore points and as send/receive targets. Snapshots are not backups — if an original block is damaged (for example by a bad sector), the snapshot is damaged too, because they share blocks.

#Creating a btrfs Filesystem

#mkfs.btrfs

Format the loopback disk:

sudo losetup -f /tmp/lab.img
sudo mkfs.btrfs -L lab-btrfs /dev/loop0

For multi-device mode, give several devices at once:

sudo mkfs.btrfs -m raid1 -d raid1 /dev/loop0 /dev/loop1

-m raid1 sets the metadata allocation mode, -d raid1 sets data. Each device can be a different size — btrfs uses the smallest device as the capacity reference for RAID1. Supported RAID modes: single, dup, raid0, raid1, raid10, raid1c3, and raid1c4.

#The Default Subvolume Structure

Mount the filesystem:

sudo mkdir -p /mnt/lab
sudo mount /dev/loop0 /mnt/lab
sudo btrfs subvolume list /mnt/lab

btrfs creates subvolume ID 5 (<FS_TREE>) as the root, then subvolume ID 257. Check the full information with:

sudo btrfs filesystem show /dev/loop0
sudo btrfs filesystem usage /mnt/lab

btrfs filesystem usage shows the metadata vs data allocation in detail.

#Subvolume and Snapshot Operations

#Creating and deleting subvolumes

sudo btrfs subvolume create /mnt/lab/data
sudo btrfs subvolume list /mnt/lab
sudo btrfs subvolume delete /mnt/lab/data

A deleted subvolume only releases its pointer; its space is freed later by a background process (and guaranteed once all COW references are released).

#Snapshots and rollback

sudo btrfs subvolume snapshot /mnt/lab/data /mnt/lab/@snap-data
sudo btrfs subvolume snapshot -r /mnt/lab/data /mnt/lab/@ro-snap
sudo btrfs subvolume delete /mnt/lab/data
sudo btrfs subvolume snapshot /mnt/lab/@ro-snap /mnt/lab/data

-r creates a read-only snapshot that's safe as a restore point. The rollback pattern above is the standard technique for returning a system to a previous state.

#Balance, Device, Check, and Scrub

#btrfs balance

Balance redistributes data and metadata across devices, for example after adding a disk:

sudo btrfs device add /dev/loop2 /mnt/lab
sudo btrfs balance start -dusage=60 /mnt/lab

-dusage=60 moves data blocks that are under 60 percent used, so free space accumulates on the new device. Balance can be limited with -dlimit=, -musage=, and profile filters.

#btrfs device

Manage the members of a multi-device filesystem:

sudo btrfs device stats /mnt/lab
sudo btrfs device usage /mnt/lab

#btrfs check and scrub

sudo btrfs scrub start /mnt/lab
sudo btrfs scrub status /mnt/lab

scrub reads all data and metadata, verifies checksums, and repairs blocks from other copies when possible. btrfs check --repair is the last-resort repair tool and may only be run on an unmounted filesystem — we'll dig deeper in episode 11.

#Send and Receive

#Replication with send/receive

btrfs send produces a stream of changes that can be sent to another filesystem (local or remote over ssh) and applied with btrfs receive:

sudo btrfs send /mnt/lab/@ro-snap | ssh remote "btrfs receive /mnt/backup"

The stream may only come from a read-only snapshot. Once it runs, verify the result on the remote side. This send/receive combination is the foundation of btrfs replication and offsite backup — we'll cover incremental patterns in episode 9.

#Conclusion

btrfs changes how you think about filesystems: instead of overwriting data, everything is pointers that can be redirected. Subvolumes organize data, snapshots provide instant protection, send/receive handles replication, and scrub maintains integrity. These features come at a cost: COW operations are more complex and require management discipline.

Key takeaways:

• COW writes new blocks then changes the pointer; snapshots become nearly instant.
• Every btrfs block has a checksum; scrub verifies and repairs.
• Read-only snapshots are required for send/receive and restore points.
• btrfs balance redistributes allocation across devices.
• btrfs RAID modes support single, dup, raid0, raid1, raid10, raid1c3/4.
• Snapshots are not backups — physical blocks are still shared.

In the next episode, episode 6, we cover ZFS: pools, datasets, and snapshots — a filesystem and volume manager in one that combines RAID, checksums, and snapshots into a single entity. You'll create pools, datasets, snapshots, and do send/receive with OpenZFS.