Fedora’s Btrfs Default: How Subvolumes and Snapshots Simplify Recovery

When a system update leaves Fedora unbootable

Imagine you apply a routine dnf upgrade, reboot, and the system drops to a rescue shell because a critical service failed to start. Reinstalling is overkill; you just need to roll back the offending changes. Fedora’s default Btrfs layout makes that rollback possible with a single command, provided you have a recent snapshot.

Why Fedora chose Btrfs as the default filesystem

Starting with Fedora 33, the Workstation edition ships with Btrfs as the root filesystem. The decision rests on three core features:

• Copy‑on‑write (CoW) – writes go to new blocks, preserving the original data until the transaction commits.
• Subvolumes – logical namespaces inside a single filesystem that can be mounted independently, allowing separate / and /home trees without separate partitions.
• Instant snapshots – a snapshot is a read‑only view of a subvolume at a point in time, created almost instantly because it merely records the existing block pointers.

These properties give Fedora users built‑in version‑like safety for the operating system while keeping the installation simple.

Subvolume layout and instant snapshots

After a fresh install, running sudo btrfs subvolume list / shows two primary subvolumes:

ID 256 gen 1234 top level 5 path @
ID 258 gen 1235 top level 5 path @home

The @ subvolume holds the root tree (/), and @home holds user data. Because they are subvolumes, you can snapshot either one without affecting the other.

Fedora installs the Snapper tool by default, which hooks into dnf transactions. Each time you install, update, or remove a package, Snapper creates a pre snapshot and a post snapshot. Listing them is straightforward:

sudo snapper -c root list

The output shows columns like # (snapshot number), Type, Date, and Description. A typical pre snapshot might be labeled pre‑dnf‑upgrade.

Managing space, compression and reporting quirks

Btrfs transparently compresses data (default algorithm is zstd with level 3). This means the filesystem can store more data than the raw block count suggests. However, tools like df report the allocated space, not the logical space after compression, which can be confusing.

To see the real usage, run:

sudo btrfs filesystem usage /

The output breaks down:

• Data, compressed – actual size after compression.
• Data, uncompressed – size if compression were disabled.
• Metadata – overhead for filesystem structures.
• Global reserve – space set aside for emergency operations.

If you notice df showing 20 GB used while btrfs filesystem usage reports 12 GB compressed data, the difference is due to compression and shared blocks between snapshots.

Trade‑offs and practical limits

While Btrfs brings powerful features, it is not a universal silver bullet:

• Fragmentation impact – heavily fragmented files (e.g., large VM images or databases) can suffer from CoW overhead because each write creates a new copy, increasing fragmentation over time.
• Snapshot management not automated – the base install keeps snapshots, but it does not automatically delete old ones. Without a cron job or a tool like snapper‑cleanup, snapshots can consume space indefinitely.
• RAID‑5/6 caveats – Fedora does not enable Btrfs RAID‑5/6 by default due to known write‑hole issues; stick to single‑device, RAID‑1, or RAID‑10 unless you understand the risks.

A practical way to check whether snapshot growth is becoming problematic is to monitor the Snapshot section of btrfs filesystem usage over time. If the Snapshot column steadily rises, consider setting a retention policy.

Actionable steps: try a snapshot yourself

You can experiment with Snapper without risking your system. The following steps create a manual snapshot, make a harmless change, and then roll back.

1. Install Snapper (if not present)

   sudo dnf install snapper
   

   Run this in a terminal with sudo privileges.

2. Create a read‑only snapshot of the root subvolume

   sudo snapper -c root create --description "manual-test"

   This records the current state of @.

3. Verify the snapshot exists

   sudo snapper -c root list
   

   Look for the newest entry with the description you set.

4. Make a test change

   echo "# test comment" | sudo tee -a /etc/sysctl.conf
   

   This appends a line to a configuration file.

5. Roll back to the snapshot

   # Find the snapshot number from the list, e.g., 42
   sudo snapper -c root rollback 42
   

   Snapper will set the default subvolume to the snapshot and schedule a reboot. After reboot, the change you made in step 4 will be gone.

6. Confirm the rollback

   grep "# test comment" /etc/sysctl.conf
   

   The command should return no output, confirming the rollback succeeded.

Risks and checks: Rolling back reverts the entire root subvolume to the snapshot state, which includes any package changes made after the snapshot. Always ensure you have a recent backup of important data in /home (which is a separate subvolume and unaffected by root rollbacks). After the rollback, you can run sudo dnf history to see which transactions were removed.

By understanding how Fedora’s Btrfs layout works, you can leverage snapshots for quick recovery, keep an eye on space usage with the proper tools, and know where the trade‑offs lie—making your system both resilient and efficient.