On Wed, Jan 19, 2022 at 6:08 AM Colin Walters <walters@xxxxxxxxxx> wrote: > > > > On Wed, Jan 19, 2022, at 6:38 AM, Neal Gompa wrote: > > On Wed, Jan 19, 2022 at 6:05 AM Casey Jao via devel > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > >> > >> Doesn't rpm-ostree already provide transactional, image-based updates without the use of filesystem snapshots? In addition, roofs snapshots are only really useful if they are coordinated with bootloader management, which is already built into rpm-ostree but not yet written for a hypothetical btrfs-based atomic os updater. > > > > I think the bigger value would be around being able to use filesystem > > snapshots with /var. > > Right. In the ostree model the idea is all user data (except config files in /etc) are in /var. So if you want to back up all machine-local state (including your home directories, container storage, libvirt VMs, etc.), you just need one filesystem to save. > > It could make sense to save a snapshot of /var before performing major OS upgrades. But they're not strictly related. (As an aside: personally, I think snapshots have mostly just obscure use cases versus backup systems) > > I would agree with Casey though in that the opposite case of trying to snapshot /usr (and then boot it) outside of ostree's control is likely to confuse ostree at best at least today. Yep. I've made an adjustment to emphasize the benefit of backing up "var" rather than rolling back "root" - because while that can work, it requires specialized knowledge to get the bootloader to do the right thing. And as it's possible /boot contains only new vmlinuz+initramfs compared to a potentially much older "root" snapshot. The rpm-ostree model could dispense with the "home" subvolume. But we could cross this bridge later with systemd-homed, whether to store that material in a "home" subvolume or "var" might become more clear. The sd-homed btrfs and fscrypt backends will create per user subvolumes when on btrfs. That moots the "var" and "home subvolume distinction entirely. But the distinction remains for the luks backend which is "filesystem on luks on loop" backing files, which subvolume those user backing files are ideally located on. My instinct is this matters less for installation and daily usage, and more as a logical puzzle for disaster recovery. What items need to be restored and how, in order to make a bad day less bad. 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
