< Changes
Make btrfs the Workstation and KDE default file system
Summary
LVM+ext4 has served us well, and it will remain available and supported for custom installs. The default file system for Workstation and KDE installs shall be btrfs.
Owner
- Name: Your Name
- Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
- Product: Workstation edition, and KDE spin
- Responsible WG: Workstation working group, and KDE SIG
Current status
- Targeted release: Fedora 33
- Last updated: 2020-06-19
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Problems
- Workstation issue #152:users running out of free space on either
/
or /home
Short version
The change is based on the installer's custom partitioning Btrfs preset. It's been well tested for 7 years.
The current default partitioning (LVM+ext4): vg/root LV mounted at / and a vg/home LV mounted at /home. These are separate file system volumes, with separate free/used space. The proposed default partitioning (btrfs): root subvolume mounted at / and home subvolume mounted at /home. Subvolumes don't have size, they act mostly like directories, space is shared.
Unchanged: there will still be a non-encrypted boot volume mounted at /boot, and will be ext4. A separate boot is needed to boot dm-crypt sysroot installations; and it's less complicated to keep the layout the same, regardless of whether sysroot is encrypted. There will be no automatic snapshots/rollbacks.
Optional Optimizations
The detailed description is the proposal. It's intended to be a minimalist, and transparent switch. It's also the same as proposed for Fedora 16. The following optimizations improve on the proposal, but are not critical. They are transparent to most users. The general idea is agree to the base proposal first, and then consider these as enhancements. It is straightforward and planned to document enabling these enhancements for post-install implementation, in particular for current btrfs users.
Boot on btrfs
- Instead of a 1G ext4 boot, create a 1G btrfs boot.
- Advantage: Makes it possible to include in a snapshot and rollback regime. GRUB has stable support for btrfs for 10+ years.
- Scope: Contingent on bootloader and installer team review and approval.
- Liabilities: BIOS installs may need to look at /boot/grub2 isolation from snapshot/rollback. Due to BLS, this location should never change, but then users... offers one idea but it's a bit messy.
Compression
- Enable transparent compression using zstd on select directories: /usr /var/lib/flatpak ~/.local/share/flatpak
- Advantage: Saves space and reduces write amplification, may improve performance in some instances.
- Scope: Contingent on installer team review and approval to enhance anaconda to set the proper XATTR for each directory.
- Liabilities: rsync vs rpm vs unsquashfs installs, where destination dirs must already be setup.
- Alternate: 'mount -o compress=zstd'; then install; then set the proper XATTR for each directory. The idea here is, a temporary install time only compression file system wide, which in effect compresses mostly /usr. Following creation of the directory tree, regardless of install method details, set the compression XATTR for select dirs to maintain on-going compression.
Additional subvolumes
- /var/log/ /var/lib/libvirt/ and ~/.local/share/gnome-boxes/images/ have separate subvolumes.
- Advantage: Makes it easier to excluded them from snapshots, rollbacks, and send/receive.
- Scope: Anaconda knows how to do this already, just change the kickstart to add additional subvolumes, contingent on Anaconda review and approval.
Feedback
What btrfs features are recommended and supported?
This is the upstream Btrfs feature status page
Fedora is a community project. What is supported within Fedora depends on what the community decides to put forward in terms of resources.
When in doubt, use defaults. Be patient with yourself, and each other. There are few things you must learn about btrfs, but the toy box is full. It can be overwhelming. Features that sound familiar, like raid1, don't work the same as other implementations you're familiar with. There is lots of jargon. Take your time. No one needs to go from 0 kph to 100 kph overnight.
What is possible but not supported?
No btrfs features will be disabled. The full box of toys is available. It is possible to get into trouble. You might also have more fun.
Red Hat doesn't support btrfs? Can Fedora do this?
Red Hat supports Fedora well in many things. But Fedora already works closely with, and depends on, upstreams. This will be one of them, and it is an important consideration for this proposal. The community has a stake in ensuring it is supported. Red Hat will never support btrfs if Fedora rejects it. Why would they? Fedora necessarily would need to be first, and make the persuasive case that it solve more problems than alternatives. Feature owners believe it does, hands down.
Benefit to Fedora
- Compression: Significantly reduces write amplification, and extends hardware life. It also saves space, and in some cases it will improve performance, by reducing the number of relatively slow reads and writes.
- Solves free space problems with the existing layout: Workstation Issue#152
- Cgroupsv2 support in btrfs provides IO isolation, helps complete the resource control efforts on the desktop. This improves system responsiveness when under pressure. Workstation Issue#98
- Data integrity: Hardware induced corruptions aren't common at an individual level. But at scale, such as a community, there are people who are victims already. This problem of silent data corruption is solved by detecting it, and if there's redundancy, to correct it.
- Reflinks and snapshots for improved container performance and space savings, and optional rollback capabilities.
Scope
- Proposal owners:
- Submit PR's for Anaconda to change default_scheme = BTRFS to the proper product files: Workstation, KDE.
- Multiple test days: build community support network
- Aid with documentation
- Other developers:
- Anaconda, review PRs and merge
- Bootloader team, review PRs and merge
- Release engineering: #Releng issue number
=
- Policies and guidelines: N/A
- Trademark approval: N/A
Upgrade/compatibility impact
Change will not affect upgrades.
Documentation will be provided for existing Btrfs users to "retrofit" their setups to that of a default btrfs installations (base plus any approved options).
How To Test
Today: Do a custom partitioning installation, change the scheme drop-down menu to Btrfs, click the blue "automatically create partitions" and install. Any current version of Fedora on any arch (but ideally x86_64 and ARM since those are the target arch's for Workstation and KDE).
Once the change lands: It should be simple enough to test, just do a normal install.
User Experience
Pros
- Mostly transparent
- Space savings from compression
- "Wonky" hardware may be exposed by checksumming. If something is corrupting your data, btrfs will tell you it's corrupted. But won't pin the blame on why. It's a bug hunt and it may be tedious. The alternative is getting the same corruption, but not being informed about it as often or at all.
- Utilities for used and free space, CLI and GUI, are expected to behave the same. No special commands are needed.
- More detailed information can be revealed by btrfs specific commands. Terms are reused in btrfs but can mean different things than you're used to.
Enhancements may be desired
[https://bugzilla.redhat.com/show_bug.cgi?id=906591 updatedb does not index /home when /home is a bind mount. Also can affected rpm-ostree installations, including Silverblue.
GNOME Usage: Incorrect numbers when using multiple btrfs subvolumes This isn't btrfs specific, happens with "one big ext4" volume as well.
GNOME Boxes, RFE: create qcow2 with 'nocow' option when on Btrfs /home This is btrfs specific, and is a recommended optimization for both GNOME Boxes and virt-manager.
containers/libpod: automatically use btrfs driver if on btrfs
Dependencies
None.
Contingency Plan
- Contingency mechanism: Owner will revert changes; back to LVM+ext4.
- Contingency deadline: Beta freeze.
- Blocks release? Yes
- Blocks product? Workstation x86_64/ARM and KDE x86_64.
Documentation
Strictly speaking no documentation is needed, except one very important thing. Do not use 'btrfs check --repair' except as an absolute last resort. There are almost always better ways of recovery to try first, not least of which is taking advantage of even read-only mount to refreshen backups. Just in case the repair doesn't go well.
For those who want to know more:
man 5 btrfs
contains: mount options, features, swapfile support, checksum algorithms, and more
man btrfs
contains an overview of the btrfs subcommands
man btrfs <subcommand>
will show the man page for that subcommand
NOTE: The btrfs command will accept partially subcommand as long as it's not ambiguous. These are equivalent commands:
btrfs subvolume snapshot
btrfs sub snap
btrfs su sn
You'll discover your own convention. It might be preferable to write out the full command on forums and lists, but then maybe some folks don't learn about this shortcut?
There will be some minimal Fedora documentation to help get the ball rolling.
Release Notes
The default file system is Btrfs.