On Tue, Dec 21, 2021 at 6:57 AM Ludwig Nussel <ludwig.nus...@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
