From Fedora Project Wiki
< Changes
Chrismurphy (talk | contribs) mNo edit summary |
Chrismurphy (talk | contribs) mNo edit summary |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 37: | Line 37: | ||
== Detailed Description == | == Detailed Description == | ||
/boot will be on btrfs. | /boot will be on btrfs. This is supported by GRUB for ~10 years, and recently in the installer. It will make snapshotting of /boot possible, to ensure parity with /usr on rollback. | ||
Use subvolumes for the following mountpoints: <span style=color:blue>/ | Use subvolumes for the following mountpoints: <span style=color:blue>/home /var/logs /var/lib/libvirt/images</span>. This will make it possible to avoid snapshot and rollback of logs, VM images, and user home. NOTE: the design is WIP, but also is not user facing. | ||
[ | Prior work in this area: | ||
[http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html Revisiting How We Put Together Linux System] | |||
[https://github.com/containers/bubblewrap containers/bubblewrap] | |||
== Feedback == | == Feedback == | ||
| Line 47: | Line 49: | ||
''One big file system? What about clean installs and using /home?''</br > | ''One big file system? What about clean installs and using /home?''</br > | ||
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, including having no size. | 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, including having no size. | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Optimize the | Optimize the 'btrfs preset' installation for today's use cases, and prepare for additional features. A significant benefit of btrfs is it can be a nearly drop-in replacement, and not burden users with learning esoteric things. | ||
Default features: | Default features: | ||
* One big file system, no longer run out of space on / or /home. | * One big file system, no longer run out of space on / or /home. | ||
* Full data integrity checking.ƒ | * Full data integrity checking.ƒ | ||
* Podman will use snapshots.ƒ | * (Rootless) Podman will use snapshots.ƒ | ||
Available optionally now, integration in the near future: | Available optionally now, integration in the near future: | ||
* cgroupsv2 IO isolation, completes the resource control picture for better system responsiveness.ƒ | * cgroupsv2 IO isolation, completes the resource control picture for better system responsiveness.ƒ | ||
* Transparent compression, file system/directory/file level granularity.ƒ | * Transparent compression, file system/directory/file level granularity.ƒ | ||
* Snapshots and rollbacks, restore files | * Snapshots and rollbacks, restore files using reflink copy.ƒ | ||
ƒ These are btrfs only features. | ƒ These are btrfs only features. | ||
| Line 71: | Line 72: | ||
* Other developers: | * Other developers: | ||
** Bootloader team to review and ack changes. | ** Bootloader team to review and ack changes related to /boot. | ||
** 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 92: | Line 93: | ||
* Transparent in normal use. | * 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. | * 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 | * 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, at their own pace. | * 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. | ||
== Dependencies == | == Dependencies == | ||
| Line 119: | Line 119: | ||
** [https://github.com/kdave/btrfs-progs/tree/master/libbtrfsutil btrfs-progs: libbtrfsutil] | ** [https://github.com/kdave/btrfs-progs/tree/master/libbtrfsutil btrfs-progs: libbtrfsutil] | ||
** [https://github.com/knorrie/python-btrfs knorrie/python-btrfs] | ** [https://github.com/knorrie/python-btrfs knorrie/python-btrfs] | ||
== Release Notes == | == Release Notes == | ||
Latest revision as of 04:42, 15 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-15
- 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. This is supported by GRUB for ~10 years, and recently in the installer. It will make snapshotting of /boot possible, to ensure parity with /usr on rollback.
Use subvolumes for the following mountpoints: /home /var/logs /var/lib/libvirt/images. This will make it possible to avoid snapshot and rollback of logs, VM images, and user home. NOTE: the design is WIP, but also is not user facing.
Prior work in this area: Revisiting How We Put Together Linux System containers/bubblewrap
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, including having no size.
Benefit to Fedora
Optimize the 'btrfs preset' installation for today's use cases, and prepare for additional features. A significant benefit of btrfs is it can be a nearly drop-in replacement, and not burden users with learning esoteric things.
Default features:
- One big file system, no longer run out of space on / or /home.
- Full data integrity checking.ƒ
- (Rootless) 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 using 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 related to /boot.
- 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: