On Sun, Jan 16, 2022 at 9:36 PM Chris Adams <li...@cmadams.net> wrote: > > Once upon a time, Chris Murphy <li...@colorremedies.com> said: > > If you value Fedora having a snapshot and rollback scheme of some > > kind, it's useful and beneficial. If you don't, then the change is > > neutral because it has not a single technical downside presented so > > far - just emotive ones. > > It's only beneficial for snapshots if you believe that only /usr > matters, which I don't believe is true.
It might be true that it's the only one that should matter, if you care to have the benefit of a clear cut snapshot and rollback design. This is the /etc/fstab for (open)SUSE Tumbleweed. $mainfsuuid / btrfs defaults 0 0 $mainfsuuid /var btrfs subvol=/@/var 0 0 $mainfsuuid /usr/local btrfs subvol=/@/usr/local 0 0 $mainfsuuid /srv btrfs subvol=/@/srv 0 0 $mainfsuuid /root btrfs subvol=/@/root 0 0 $mainfsuuid /opt btrfs subvol=/@/opt 0 0 $mainfsuuid /home btrfs subvol=/@/home 0 0 $mainfsuuid /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0 $mainfsuuid /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0 $mainfsuuid /.snapshots btrfs subvol=/@/.snapshots 0 0 $swapfsuuid swap swap defaults 0 0 $espfsuuid /boot/efi vfat utf8 0 2 It lacks a separate line for /var/tmp/rpm, which it would otherwise need, because the rpmdb is in /usr. It looks like this because /usr isn't the only thing that's important. These carve outs exist because it was easier to do with Btrfs subvolumes (effectively bind mounts behind the scenes) than (a) with individual file systems or (b) committing to reorganizing the filesystem hierarchy. Now (open)SUSE is doing the hard work to reorganize the filesystem hierarchy where RPM only touches /usr. If we're feeling bold and maybe even brazen, maybe we'd pull everything out of /usr /var /etc that can be called 'the system'. Specifically, that which is system critical for the purpose of booting and startup. Things that get us to a working login prompt, but not beyond that (or at least not much beyond it). Stick all of that into a new top-level directory called "system". Within that could be usr/ var/ etc/ if you want. This "system" subvolume or LV is what would be subject to snapshot and rollback. This could be done with metadata defining what individual files are "system critical" so that 'dnf history rollback' could do a fine grained revert for such those files. But that presumes we can even boot to a system sufficiently working that this command could succeed. I think it's better to have a system that's prepared for the possibility an update can introduce trouble, and has the ability to detect failure and reboot to a previous known working state. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
