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 optimal Btrfs configuration (including /boot on Btrfs, potentially as a 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 33
- Last updated: 2020-01-29
- 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. Adjust the default proposed Btrfs layout by Anaconda to be more optimal (potentially derived from the openSUSE one).
2. Add support for automatically configuring Snapper and the Snapper DNF plugin on Btrfs installs
3. 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: #7591 (a check of an impact with Release Engineering is needed)
- List of deliverables:
- Live Media: Addition of
snapperanddnf-plugin-snapperon all images - Install DVD: Addition of
snapperanddnf-plugin-snapperfor Anaconda to install when Btrfs is selected - Netinstall: Addition of
snapperanddnf-plugin-snapperfor Anaconda to install when Btrfs is selected
- Live Media: Addition of
- List of deliverables:
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
N/A (enables new functionality previously unavailable in Fedora)
How To Test
Basic flow:
- Set up the system fully on Btrfs
- Ensure snapshots are taken when package management actions happen
- Verify the snapshot is registered and able to be selected to boot from in the boot menu
- Verify 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
- snapper
- dnf-plugins-extras
Contingency Plan
- Contingency mechanism: Disable auto-configuration of snapper in Anaconda.
- Contingency deadline: Beta freeze
- Blocks release? Yes
- Blocks product? N/A