Chrismurphy (talk | contribs) mNo edit summary |
Chrismurphy (talk | contribs) mNo edit summary |
||
| Line 67: | Line 67: | ||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: | ||
** Implement /boot on dedicated ~ | ** Implement /boot on dedicated ~1G btrfs volume with 'boot' subvolume | ||
** Design a subvolume layout focusing on snapshot and rollback functionality, and modify the btrfs preset kickstart accordingly. | ** Design a subvolume layout focusing on snapshot and rollback functionality, and modify the btrfs preset kickstart accordingly. | ||
* Other developers: | * Other developers: | ||
** Bootloader team to review and ack changes. | ** Bootloader team to review and ack changes. | ||
** Anaconda to review and merge changes. | ** Anaconda to review and merge changes. | ||
** Might affect dnf snapper plugin behavior. | ** Might affect dnf snapper plugin behavior. | ||
| Line 96: | Line 95: | ||
* Podman can use snapshots (default) or reflinks+overlayfs, at user discretion. Both are faster and more space efficient operations, than copy up on ext4. | * Podman can use snapshots (default) or reflinks+overlayfs, at user discretion. Both are faster and more space efficient operations, than copy up on ext4. | ||
* Users can opt-in to other btrfs features: snapshots, compression, <span style=color:red>cp --reflink</span> efficient copies, online scrub, btrfs send/receive | * Users can opt-in to other btrfs features: snapshots, compression, <span style=color:red>cp --reflink</span> efficient copies, online scrub, btrfs send/receive, at their own pace. | ||
Revision as of 08:20, 13 June 2020
Improve the Anaconda Btrfs preset
Summary
A few small changes will make it easier to do snapshots and rollbacks on btrfs, in the near future.
Owner
- Name: Chris Murphy
- Email: chrismurphy@fedoraproject.org
- Product: Anaconda
- Responsible WG: Workstation, KDE SIG
Current status
- Targeted release: Fedora 33
- Last updated: 2020-06-13
- 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
/boot will be on btrfs. [1]
Use subvolumes for the following mountpoints: /etc /var /opt /root/root /srv /usr/local
[1] /boot on btrfs is supported by GRUB for ~10 years; makes snapshotting of /boot possible, to ensure parity with /usr on rollback; needs design review and resource assessment.
Feedback
One big file system? What about clean installs and using /home?
Anaconda custom partitioning will let you reuse an existing 'home' subvolume to mount at '/home', without a reformat. A new 'root' subvolume must be created for '/' however. NOTE: Subvolumes are a bit special, but act mostly like directories. Importantly, they have no size.
Benefit to Fedora
Optimize the default btrfs installation for today's use cases, and prepare for additional features.
Default features:
- One big file system, no longer run out of space on / or /home.
- Full data integrity checking.ƒ
- Podman will use snapshots.ƒ
Available optionally now, integration in the near future:
- cgroupsv2 IO isolation, completes the resource control picture for better system responsiveness.ƒ
- Transparent compression, file system/directory/file level granularity.ƒ
- Snapshots and rollbacks, restore files by reflink copy.ƒ
ƒ These are btrfs only features.
Scope
- Proposal owners:
- Implement /boot on dedicated ~1G btrfs volume with 'boot' subvolume
- Design a subvolume layout focusing on snapshot and rollback functionality, and modify the btrfs preset kickstart accordingly.
- Other developers:
- Bootloader team to review and ack changes.
- Anaconda to review and merge changes.
- Might affect dnf snapper plugin behavior.
- Policies and guidelines: N/A
- Trademark approval: N/A
Upgrade/compatibility impact
This change will not apply to upgrades.
How To Test
Install and use the system however you usually do, and it should behave the same.
User Experience
- Transparent in normal use.
- Always-on integrity verifies metadata and data. Corrupt data results in EIO, it never reaches user space. User is notified by kernel message about affected files by path.
- Podman can use snapshots (default) or reflinks+overlayfs, at user discretion. Both are faster and more space efficient operations, than copy up on ext4.
- Users can opt-in to other btrfs features: snapshots, compression, cp --reflink efficient copies, online scrub, btrfs send/receive, at their own pace.
Dependencies
None
Contingency Plan
- Contingency deadline: Revert all changes.
- Blocks release? Yes.
- Blocks product? Workstation/KDE are release blocking desktops.
Documentation
The user is not expected to know btrfs specific things for day to day use.
man 5 btrfs - for information about general btrfs information, mount options, and features.
man btrfs - for information about the btrfs command and sub commands. NOTE: Subcommands can be arbitrarily shortened, as long as it isn't ambiguous. 'btrfs fi us' is the same as 'btrfs filesystem usage'.
- Users and developers alike, may be interested in: