[systemd-devel] the need for a discoverable sub-volumes specification

[Chris Murphy]

On Tue, Dec 21, 2021 at 6:57 AM Ludwig Nussel <ludwig.nussel at suse.de> wrote:
>
> Chris Murphy wrote:

> > The part I'm having a hard time separating is the implicit case (use
> > some logic to assemble the correct objects), versus explicit (the
> > bootloader snippet points to a root and the root contains an fstab -
> > nothing about assembly is assumed). And should both paradigms exist
> > concurrently in an installed system, and how to deconflict?
>
> Not sure there is a conflict. The discovery logic is well defined after
> all. Also I assume normal operation wouldn't mix the two. Package
> management or whatever installs updates would automatically do the right
> thing suitable for the system at hand.

rootflags=subvol/subvolid= should override the discoverable
sub-volumes generator

I don't expect rootflags is normally used in a discoverable
sub-volumes workflow, but if the user were to add it for some reason,
we'd want it to be favored.


>
> > Further, (open)SUSE tends to define the root to boot via `btrfs
> > subvolume set-default` which is information in the file system itself,
> > neither in the bootloader snipper nor in the naming convention. It's
> > neat, but also not discoverable. If users are trying to
>
> The way btrfs is used in openSUSE is based on systems from ten years
> ago. A lot has changed since then. Now with the idea to have /usr on a
> separate read-only subvolume the current model doesn't really work very
> well anymore IMO. So I think there's a window of opportunity to change
> the way openSUSE does things :-)

I think the transactional model can accommodate better anyway, and is
the direction I'd like to go in with Fedora. Make updates/upgrades
happen out of band (in a container on a snapshot). We can apply
resource control limits so that the upgrade process doesn't negatively
impact the user's higher priority workload. If the update fails to
complete or fails a set of simple tests - the snapshot is simply
discarded. No harm done to the running system. If it passes checks,
then its name is changed to indicate it's the favored "next root"
following reboot. And we don't have to keep a database to snapshot,
assemble, and discard things, it can all be done by naming scheme.

I think the naming scheme should include some sort of "in-progress"
tag, so it's discoverable such a sub-volume is (a) not active (b) in
some state of flux that potentially was interrupted (c) isn't critical
to the system. Such a sub-volume should either be destroyed (failed
update) or renamed (update succeeds). If the owning process were to
fail (crash, powerfailure), the next time it runs to check for
updates, it would discover this "in-progress" sub-volume and remove it
(assume it's in a failed state).


-- 
Chris Murphy