Re: BTRFS/Rollback & Yum Snapshot Plugin
On 02/03/2014 03:16 PM, Chris Murphy wrote:
Yes, there are challenges, much of which are the result of
unanswered
questions. For example:
What should the layout be? (See opensuse's layout for an alternative to
Fedora's.) How discoverable should this be for mortal users vs experts?
How far back should rootfs snapshots be bootable? Should snapshots
initially be read-only? Maybe. If a snapshot is rw, and then booted, it's
immediately changed, and if it's further changed by being updated or
modified by the user, is it really a snapshot of a file tree in a
particular state? No.
If snapshots are read-only, how do we boot them? What system changes are
needed for rootfs to always be ro in normal use, and only made rw when
there's a system update? Or alternatively, when doing the rollback, do we
make a rw snapshot of the ro snapshot, and boot the rw version? And then
how do we clean up all of the ensuing snapshots?
These are all excellent questions. Some which I never imagined!
Also, the fstab in all of the snapshots are wrong. An unmodified
fstab in
a snapshot causes the parent subvolume of all snapshots to be mounted,
not the snapshot. There are multiple ways to solve this, it's not so much
a technical problem as it is a "determining best practices" by imagining
many use cases, and figuring out the liabilities of each potential
solution.
I haven't follow the openSUSE community for years. Do you think they've
nailed most of these issues? or all distros on the same boat ?
My impression is that , until it gets to be the default filesystem on
most distros, these issues (of rolling back system via snapshots) won't
get much attention. Do you agree?
Also, /boot quickly will contain updated kernels that can't boot
old
snapshots because the snapshots only contain older kernel modules. So
that implies /boot needs snapshotting. Or we need limited
snapshot/rollback to maybe just one older kernel. The main holdup for
/boot on Btrfs is an old grubby bug RHBZ# 864198. Also, the freedesktop
bootloaderspec calls for $BOOT being a non-snapshotable file system,
while also being too small to accumulate many kernel+initramfs files so
that old snapshots can be booted.
Interesting stuff about /boot.
For what it's worth, currently both the yum plugin and snapper
presume
the parent subvols are the ones persistently used and modified; the
snapshots are children and in normal operation aren't ever used. If a
rollback is needed, it's the "child" snapshots that are used. This
isn't
the only way to do it. It's equally valid to snapshot the parent, modify
and use the child in normal operation, and rollback to the parent. An
advantage is that the parent subvol name and its fstab are already
properly in sync, the child snapshot subvolume(s) of course have new
names and are used in the modified fstab.
At this point I don't see any value for the yum plugin. It simply does
the autoamtic snapshotting before applying updates. It flies the
airplaine but doesn't land it. That is, the advanced user who knows how
to: modify GRUB, fstab, specify subvolume, in order to rollback its
system, already knows how to create the snapshot in the first place.
I haven't played with snapper. I don't know if it just a tool to
create/delete/manage/rotate snapshots or if it automates all of these
things in order to rollback your system. I'm still learning the basics
of btrs so I wanted to avoid any front-end tools.
Note also that opensuse has a different layout for all of this than
Fedora. They make the default subvolume ID 5 (the top level of the Btrfs
file system, the first subvolume, the one that can't be deleted or named)
the parent and mount it at /. And then create the following subvolumes:
boot/grub2/x86_64-efi
home
opt
srv
tmp
usr/local
var/crash
var/log
var/opt
var/spool
var/tmp
Interesting. I think Fedora's way looks more simple. I guess there are
pros & cons for each.
So which is the more discoverable layout? Well it depends on
one's point
of view. The expert who mounts a Fedora install on Btrfs doesn't see the
linux FHS, and becomes confused initially. They see what looks like two
directories: root and home (on Fedora 19 they might also see boot if they
opted to put /boot on Btrfs). Because the mount command doesn't show the
subvolume that's mounted, the assembly of the on-disk layout into the
mounted file system isn't obvious. It only becomes clear once
understanding subvolumes can be (almost completely) independently
mounted, and looking at /etc/fstab which shows the subvol= mount option.
Anyway, point is, even in the infant stage of Btrfs as a root file
system, two distros have two completely different layouts and
snapshotting behaviors. I've argued that we need some interdistro
conversation on something like an FHS addenda that tackles some
standardization or best practices for how to organize such file systems
and their snapshots. It probably should also account for LVM thin
provisioning, which enables somewhat similar functionality. Or we'll just
have to live with ensuing messiness.
And standardization is better for bootloader development too, so that we
don't have all of these different distro patches accounting for six ways
to Sunday boot strategies. More like 60 ways…
I totally agree with all of the above.
Not last, not least, is GRUB. It has several pieces, and relevant
different behaviors on BIOS and UEFI that I won't bring up here. However,
there are some ideas how to make a static grub.cfg dynamically produce
entires for Btrfs snapshots on grub-devel@, and I think that's more
useful than always rewriting grub.cfg.
But yes, I wish it were more polished too.
Thanks a lot for your thoughtful insight about the current situation.
It's very much appreciated.
All the best,
Jorge