On Fri, Jul 17, 2015 at 11:27 AM, Andrei Borzenkov
В Wed, 15 Jul 2015 22:05:44 -0600 Chris Murphy
пишет: Starting with systemd 219, it automatically creates subvolumes for nspawn containers at /var/lib/machines. And there's also an commit sometime in March/April that brings snapshot and rollback control of containers into machinectl which leverages btrfs snapshotting.
Has anyone using Factory looked at how snapper behaves when doing rollbacks? I'm pretty sure the following will happen:
The snapshot of the top level of the file system done by snapper will stop at /var/lib/machines/ and not include any of the subvolumes in it. That's not the problem though. The problem happens if you do a rollback, and of course now the /var/lib/machines directory will be empty. All of your containers are in a different subvolume.
Well, as soon as you start messing around with snapshots and rollbacks you need to have explicit indication of mount point for each subvolume. /etc/fstab is as good as anything. ZFS solves it differently and IMNSHO much more elegant. It has no issues with rollbacks.
It has lots of issues with rollbacks, seeing as it has such a concept and Btrfs doesn't. And this rollback concept provides a clearer path for what should be done, rather than it being rather self-guided like Btrfs.
I don't think it's snappers job to do a recursive snapshot in order to make sure these containers are present in every snapshot. This explodes the number of subvolumes. It duplicates snapshotting (both machinectl and snapper).
I think this is "yet another example" of why nested subvolumes usually aren't a good idea.
Tell that ZFS folks. Do not confuse implementation with idea.
The reason why it is more sane on ZFS is because there is an explicit
parent-child relationship with ZFS snapshots, and no such thing as
writable snapshots. A writable clone on ZFS is different than a Btrfs
writable (by default) snapshot. And on Btrfs there is no explicit
parent-child relationship with snapshots, this is included in the
metadata in the form of UUID, but it's completely valid to delete the
"parent" or origin subvolume for a "child" snapshot - that snapshot
remains unchanged. This can't be done on ZFS where you have to delete
all children before the volume can be deleted.
When doing rollbacks on ZFS, intermediate snapshots are deleted,
because you can only rollback to the most recent snapshot. Changes
since the snapshot are discarded. And again Btrfs doesn't have this
concept at all. Every snapshot is merely a pre-populated subvolume,
that's completely independent from the original. The one thing that
indirectly ties it to the original is the parent subvolume UUID.
The bootloader and its configuration could specify a subvolume to boot
by path (which should always be relative to