Learn Linux Filesystem - Advanced btrfs

#Introduction

btrfs is the fastest-evolving filesystem in the Linux ecosystem. Episode 5 covered the basics; episode 13 gets into the features that have matured in recent years — from block-group-tree, which became the default, triple-copy redundancy profiles, to btrfs-progs 7.x tooling.

These features matter to anyone considering btrfs for production: many-disk storage, compression, and more precise allocation management. Some are still experimental — we'll mark them clearly.

We'll start with the most important architectural change, then the tooling, and finish with technology still in active development.

#Block-Group-Tree

#Why Block-Group-Tree Was Introduced

On old btrfs, block group information (groups of blocks with the same allocation profile) was stored in the extent tree. When a filesystem fills up, this tree becomes very large and allocation operations slow down. Block-group-tree separates block group metadata into its own tree, making reads and allocations much faster.

Block-group-tree became the default since kernel 6.19 and btrfs-progs 6.12+. Check whether your filesystem uses it:

sudo btrfs inspect-internal dump-super /dev/loop0 | grep -i compat

The output shows compat_ro_flags, which includes block-group-tree if enabled.

#Converting Old Filesystems

This feature can be added to an existing filesystem at boot, via a special mount option:

mount -o block-group-tree /dev/loop0 /mnt/lab

Once enabled and mounted, block-group-tree is used for new allocations. Make sure your kernel and btrfs-progs are new enough before enabling it.

#Redundancy Profiles: raid1c3 and raid1c4

#Three or Four Copies

btrfs supports RAID profiles beyond the common ones. raid1c3 stores three copies of data and metadata; raid1c4 stores four. These suit many-disk setups with very high protection needs:

sudo mkfs.btrfs -m raid1c3 -d raid1c3 /dev/loop0 /dev/loop1 /dev/loop2

Unlike standard raid1, which keeps only two copies, raid1c3 survives two simultaneous disk failures. Its allocation requires at least three devices, and each copy is placed on a different device.

#When to Use It

• raid1c3: critical storage with three disks — a balance of cost and protection.
• raid1c4: four copies for data that must never be lost, at any price.

Note that raid5 and raid6 on btrfs are still considered experimental; raid1c3/raid1c4 are a safer alternative for double redundancy.

#Compression and Balance Filters

#Choosing a Compression Algorithm

btrfs supports zstd, lzo, and zlib. A brief comparison:

• zstd: best ratio, fast, and levels can be adjusted — the default recommendation.
• lzo: fastest, lower ratio — good for frequently read data.
• zlib: highest ratio, slow — for static archives.

Set it at mount or per-subvolume:

sudo mount -o compress=zstd:3 /dev/loop0 /mnt/lab

compress=zstd:3 uses zstd level 3 — balanced between speed and ratio. Compression is transparent: files are read back without manual decompression.

#Balance with Filters

Balance redistributes allocation. With filters, you control precisely what gets moved:

sudo btrfs balance start -dusage=60 -musage=50 /mnt/lab

-dusage=60 moves data blocks under 60 percent usage; -musage=50 for metadata. Filters can be combined with -dlimit, -ddevid, and -dprofiles to target specific destinations.

#qgroups for Space Management

#qgroups and Hierarchy

qgroup (quota group) accounts for usage while considering COW-shared blocks between subvolumes — something traditional quotas can't do:

sudo btrfs quota enable /mnt/lab
sudo btrfs qgroup show /mnt/lab

Once enabled, btrfs qgroup show displays unique and shared usage per group. This is the foundation for accurate usage reporting on systems with many snapshots.

#Limits and Performance

qgroups can limit a group's usage:

sudo btrfs qgroup limit 10G 1/100 /mnt/lab

Note: enabling qgroups on a write-heavy filesystem adds overhead. Enable them only if you truly need per-subvolume usage reporting.

#btrfs-progs 7.x

#btrfs property and check Improvements

btrfs-progs 7.x (v7.1 is the latest version at the time this series was written) brings significant improvements:

• Better btrfs property for setting subvolume properties like compression and flags.
• More reliable btrfs check for corruption cases that previously failed.

sudo btrfs property get /mnt/lab
sudo btrfs property set /mnt/lab compression zstd

btrfs property shows and sets filesystem properties declaratively — a modern way to replace editing mount options one by one.

#Remap Tree: Partial Block COW

One of btrfs's development directions is the remap tree — an experimental mechanism to enable partial COW on shared blocks. With a remap tree, large shared blocks can be split partially, reducing excess space usage when a snapshot is modified in a small portion. This feature is still experimental and not for production.

#Conclusion

Advanced btrfs shows the direction of modern filesystems: allocation efficiency (block-group-tree), flexible redundancy (raid1c3/raid1c4), adjustable compression, and qgroup-based space management. With btrfs-progs 7.x, the tooling is starting to catch up with kernel features.

Key takeaways:

• Block-group-tree separates allocation metadata — default since kernel 6.19.
• raid1c3 and raid1c4 give three to four copies for extra protection.
• zstd is the default compression recommendation; levels can be adjusted.
• Balance filters limit block movement precisely.
• qgroups account for usage including COW-shared blocks.
• The remap tree is still experimental — watch the btrfs-progs 8.x roadmap.

In the next episode, episode 14, we cover advanced ZFS (OpenZFS 2.4) — BRT for fast dedup, stable RAIDZ expansion, AnyRaid, default quotas, special vdevs, zfs rewrite, and recordsize/ashift tuning. You'll see where ZFS stands in 2026.