Btrfs with Full System Snapshots

Summary

This change is about fixing the remaining issues in the installer, bootloader setup, and software management stack so that when a user selects a Btrfs-based installation in Fedora, it will set up Btrfs with an optional Btrfs configuration (including /boot as a btrfs subvolume) and be configured such that full OS snapshots are made for each package management transaction, which the correct configuration installed to the boot loader such that the user can boot into the older state if necessary.

Owner

Name: Neal Gompa
Email: ngompa13@gmail.com
Release notes owner:

Current status

Targeted release: Fedora 29
Last updated: 2018-06-27
Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Btrfs is a next-generation volume-managing filesystem that provides facilities for spanning multiple disks with integrated RAID, cheap file system snapshots due to its copy-on-write nature, and strong integrity though data and metadata checksumming. However, in Fedora, the ability to take advantage of this has been handicapped by issues across Fedora-specific tools at the lower levels of the distribution that kept us from using these features to their fullest extent.

This change encompasses the work to fix these issues in those tools so that if a user wishes to set up Fedora with Btrfs, they get a first-class experience using the filesystem.

Benefit to Fedora

This will enable users on Fedora to finally be able to use a full Btrfs disk configuration without custom work outside of the installer. It will also help with improving the safety of software updates for those using Btrfs by having the system configured to automatically generate full system snapshots and boot entries for those snapshots for rescue/recovery purposes. In addition, this will enable future work on interesting custom alternative approaches for producing appliances (such as appliances built so that they receive updates via btrfs send/receive atomically and re-root) without unusual tooling.

Scope

Proposal owners:

1. Remove the restriction on /boot as a Btrfs subvolume in Anaconda

2. Adjust the default proposed Btrfs layout by Anaconda to be more optional (potentially derived from the openSUSE one). This may also include moving rpmdb from /var/lib/rpm to /usr/lib/sysimage/rpm as openSUSE did (and Atomic/CoreOS has done) to maintain a simpler subvolume layout. This will also involve fixing the SELinux policy so that /usr/lib/sysimage/rpm is treated the same as /var/lib/rpm. (See this and this for rationale.)

3. Add support for automatically configuring Snapper and the Snapper DNF plugin on Btrfs installs

4. Enable Snapper's ability to generate boot entries for GRUB 2 with the snapper plugin (or alternatively use Boom with snapper if we're using BLS)

Other developers:

1. Include snapper and dnf-plugin-snapper in the live/install media so that it can be configured.

Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- List of deliverables:
  - Live Media: Addition of snapper and dnf-plugin-snapper on all images
  - Install DVD: Addition of snapper and dnf-plugin-snapper for Anaconda to install when Btrfs is selected
  - Netinstall: Addition of snapper and dnf-plugin-snapper for Anaconda to install when Btrfs is selected

Policies and guidelines: N/A (not needed for this Change)

Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Most aspects of this Change do not impact upgrades, except for one. If the the rpmdb moves from /var/lib/rpm to /usr/lib/sysimage/rpm, then the major upgrade impact will be that /var/lib/rpm becomes a symlink to /usr/lib/sysimage/rpm. This migration will happen automatically.

How To Test

If the rpmdb is moved, then an upgrade test is required to verify that package management works post-rpmdb move.

The remaining test case would be to validate that a Btrfs install does the following:

Sets up the system fully on Btrfs
Takes snapshots when package management actions happen
The snapshot is registered and able to be selected to boot from in the boot menu
The boot-to-snapshot function lets you boot into that older system

N/A (not a System Wide Change)

User Experience

When users select Btrfs for the system on install, they will get a Fedora system that will automatically snapshot itself on software management actions and have the ability to select those snapshots from the boot menu to boot into for recovery purposes.

Dependencies

anaconda
boom-boot (if we're using BLS)
grub2
rpm
snapper
dnf-plugins-extras

Contingency Plan

Contingency mechanism: Revert allowing /boot as btrfs and disable auto-configuration of snapper in Anaconda. Revert rpmdb move if needed.
Contingency deadline: Beta freeze
Blocks release? Yes
Blocks product? N/A

Documentation

Release Notes

Search

Changes/BtrfsWithFullSystemSnapshots

Contents