Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 16, 2022 at 9:36 PM Chris Adams <linux@xxxxxxxxxxx> wrote:
>
> Once upon a time, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux