From Fedora Project Wiki
No edit summary
(update dependencies)
 
(8 intermediate revisions by 2 users not shown)
Line 15: Line 15:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF36]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 33: Line 33:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FPSS64EWBODIRCBYP5WAZ56FMROUPOFX/ devel thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2742 #2742]
* Release notes tracker: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2051550 #2051550]
 
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/803 #803]


== Detailed Description ==
== Detailed Description ==
Line 54: Line 54:
Users who opt into Btrfs features like snapshots and rollbacks.
Users who opt into Btrfs features like snapshots and rollbacks.


* By moving /var into its own subvolume, it will be excluded from snapshots and rollbacks of the "root" subvolume, which contains `/etc` and `/usr`.
* By moving /var into its own subvolume, it can be independently snapshot and rolled back from the "root" subvolume, which contains `/etc` and `/usr`.
* Users will find it straightforward to rollback "root" while not rolling back "var": including logs, VMs, databases, and so on.
* The ability to snapshot "var" and use Btrfs send/receive to replicate only "var" permits for an efficient way of backing up the variable system data, similar to snapshotting "home" and replicating it as a way of backing up user data.
* The ability to snapshot only "var" and use Btrfs send/receive to replicate only "var" permits for an efficient way of backing up the variable system data.
** A clean install will restore the "root", therefore it doesn't strictly need to be backed up. Meanwhile "var" and "home" can be restored using snapshot replication via send/receive, or a favorite backup utility.
** A clean install can restore the "root", therefore it doesn't strictly need to be backed up. Meanwhile "var" and "home" can be restored using snapshot replication via send/receive.




== Scope ==
== Scope ==
* Proposal owners:  
* Proposal owners:  
** changes to lorax and anaconda as needed so that Silverblue and Kinoite variants have their own installation kickstart, such that automatic/guided installation automatically creates "var".
** change anaconda Silverblue and Kinoite profiles, such that automatic/guided installation creates a "var" subvolume mounted at /var.
*** possible liability, determine whether the the addition of /var mount point for Btrfs scheme results in /var mount point for other schemes (and inhibit)




Line 88: Line 86:
== Dependencies ==
== Dependencies ==


* Anaconda/blivet, lorax, and possibly kickstarts
* Anaconda





Latest revision as of 22:45, 9 February 2022

Silverblue and Kinoite will have /var on its own Btrfs subvolume

Summary

Silverblue and Kinoite: For new clean automatic (guided) installations, create a "var" subvolume to be mounted at /var.


Owner


Current status

Detailed Description

Currently, Silverblue and Kinoite mimic other Fedora desktops. There is a "root" subvolume mounted at / and a "home" subvolume mounted at /home.

This proposal adds a "var" subvolume to be mounted at /var.

The "var" subvolume will be located at the top-level of the Btrfs file system, along-side the "root" and "home" subvolumes. An entry in /etc/fstab will mount it at /var during startup.


Feedback

Benefit to Fedora

Users who opt into Btrfs features like snapshots and rollbacks.

  • By moving /var into its own subvolume, it can be independently snapshot and rolled back from the "root" subvolume, which contains /etc and /usr.
  • The ability to snapshot "var" and use Btrfs send/receive to replicate only "var" permits for an efficient way of backing up the variable system data, similar to snapshotting "home" and replicating it as a way of backing up user data.
    • A clean install will restore the "root", therefore it doesn't strictly need to be backed up. Meanwhile "var" and "home" can be restored using snapshot replication via send/receive, or a favorite backup utility.


Scope

  • Proposal owners:
    • change anaconda Silverblue and Kinoite profiles, such that automatic/guided installation creates a "var" subvolume mounted at /var.


Upgrade/compatibility impact

Change will not be applied to upgrades. But we can document steps to apply the change to existing installations.


How To Test

  • Do a clean installation and check df and /etc/fstab for an explicitly listed /var mount point.


User Experience

  • The change won't generally be noticeable to users
  • Users will see an additional /var mount point in /etc/fstab, and df
  • Some utilities, notably backup programs like borg backup, and rsync with -x option, will treat Btrfs subvolumes as separate file systems and may not descend (recursively) into them.


Dependencies

  • Anaconda


Contingency Plan

  • Contingency deadline: beta freeze (not a System Wide Change)
  • Blocks release? No


Documentation

No significant documentation is planned other than this change proposal.

N/A (not a System Wide Change)

Release Notes