From Fedora Project Wiki
(initial description)
 
No edit summary
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
= Put /var on its own Btrfs subvolume by default, on Silverblue and Kinoite
= Put /var on its own Btrfs subvolume by default, on Silverblue and Kinoite


Line 10: Line 4:
== Summary ==
== Summary ==
Silverblue and Kinoite: For new clean automatic installs, create a "var" subvolume to be mounted at /var.
Silverblue and Kinoite: For new clean automatic installs, create a "var" subvolume to be mounted at /var.


== Owner ==
== Owner ==
Line 57: Line 52:
* 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.
* 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 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.
** 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.





Revision as of 03:23, 18 January 2022

= Put /var on its own Btrfs subvolume by default, on Silverblue and Kinoite


Summary

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


Owner


Current status

  • Targeted release: Fedora Linux 36
  • Last updated: 2022-01-18
  • 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

Currently, Silverblue and Kinoite mimic other Fedora desktops. There is a "root" subvolume mounted at / and a "home" subvolume mounted at /home. This proposal will add a "var" subvolume to be mounted at /var. It will be located at the top-level of the Btrfs file system, along-side the "root" and "home" subvolumes, with an entry in /etc/fstab to mount it into the proper position during startup.


Feedback

Benefit to Fedora

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.
  • Users will find it straightforward to rollback "root" while not rolling back "var": including logs, VMs, databases, and so on.
  • 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 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

  • 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".
      • possible liability, determine whether the the addition of /var mount point for Btrfs scheme results in /var mount point for other schemes (and inhibit)
  • Other developers:
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives:

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/blivet, lorax, and possibly kickstarts


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • 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