On Wed, Jan 19, 2022 at 6:08 AM Colin Walters <walters(a)verbum.org> 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(a)lists.fedoraproject.org> 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
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"
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.