On Mon, 10.03.14 14:53, Chris Murphy (li...@colorremedies.com) wrote:
> Since it's not a given whether a parent or child subvolume is the one
> being updated, it's ambiguous which one to use/automount if there is
> inheritance of the proposed subvolumetypeGUID at snapshot
> time. Inheritance of the proposed GUID at snapshot time sounds
> untenable.
>
> Failsafe for rootfs is to snapshot, mount it, apply updates to the
> snapshot in a chroot. That way a failed update means the snapshot can
> be immediately deleted. And the OS is overall more stable by not
> having running binaries modified or yanked out from under it. Here,
> using the current subvolume at reboot is the rollback; changing to the
> snapshot is the upgrade.
>
> Whereas for home, rebooting to the snapshot is a rollback, which I
> certainly don't want by default.
>
> I don't see the right way to handle this automatically or by default.
I am in no way bound to the idea of having subvolume type UUIDs for
this. There are other options. For example, there's already the concept
of having "default" subvolumes ("btrfs subvolume set-default"...), maybe
we can extend that a little bit, and allow different kinds of default
subvolumes, one "default /home subvolume", one "default /srv subvolume",
and so on, plus one "default root subvolume", and so on. The vocabulary
for the available "default" subvolumes could be a free-form string where
the empty string would be the existing default subvolume. Or so...
When people play games with subvolumes and snapshots we could then
simply ask them to update where these "default" subvolumes point... Of
course this simply exports to the admin the problem of combining
subvolumes properly.
Another option would be to introduce a high level concept of a
"subvolume set" or so, which binds subvolumes together, and of which
there could be a "default subvolume set". Within such a subvolume set
could then use type uuids or so to mount things properly. Or something
like that...
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
