FWIW You don't need to edit the bootloader to point to a new snapshot, you can tell
btrfs which snapshot to use by default on mount time
----- Original Message -----
From: "Colin Walters" <walters(a)verbum.org>
To: "Chris Murphy" <lists(a)colorremedies.com>
Cc: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org>
Sent: Friday, 14 March, 2014 1:29:49 PM
Subject: Re: Technical Spec, better upgrade/rollback control
On Fri, Mar 14, 2014 at 12:16 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
How about hard link deletion time? When a tree is to be discarded, we may be talking about
tens of thousands of hardlinks being unlinked, right? Snapshot deletion is nearly instant
(some background clean-up does happen).
Yep, just try the reverse operation:
cp -al /usr /usr2
time rm -rf /usr2
It's ~8s for me on XFS+LVM on Samsung SSD, which I'm happy enough with. When we
get to the point where we're consistently debating update performance and not
reliability, I'll be happy.
What about permissions/selinux policy updates, or relabeling? A hard link can't have
different permissions/context than the file it points to. If an update requires file
metadata update, then I'm guessing to preserve the original state of a tree, this
would require creating a copy of the file rather than a hard link?
Yes...but the OSTree client and server don't "know" that it's a copy.
OSTree is object-based, not delta based. Every time any RPM changes, we redo a full
install, and relabel on the server side, then commit that.
(I do this because I demand there is *zero difference* between a fresh install and an
upgrade - this removes a lot of potential package failure modes)
So a permission change will show up as a new object in objects/$checksum.
This does mean that if a file changes permission or SELinux label in an RPM, clients
redownload the entire file content. Honestly, this doesn't happen very often, and most
individual files are small anyways. Static deltas will address this as well.
If so that brings up this thread I brought up on the Fedora security list. The gist is
asking whether there's a security risk/concern if old binaries with vulnerabilities
are persistently available.
Yep, this came up before:
https://bugzilla.gnome.org/show_bug.cgi?id=722984
And yet another topic, loosely related to the needed tree switching semantics and booting.
There is a thread on Discoverable Partitions Spec on the systemd list:
http://lists.freedesktop.org/archives/systemd-devel/2014-March/017677.html
Discoverable Partitions pretty much orthogonal to OSTree.
I'm kinda liking the part of this being self-describing, usable by bootloaders and
systemd, rather than utilities like OSTree, snapper, and so on, having to become familiar
with and responsible for updating myriad bootloader configuration scripts
OSTree already uses the BLS:
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
Once syslinux and u-boot gain awareness of it, then the bootloader-specific code can be
dropped from the OSTree core.
and updating fstab properly.
OSTree doesn't touch fstab - it writes a new bootloader configuration with a new
ostree= argument that points to the correct root.
But you know more about these pitfalls so this is mostly a heads up to see if you have
some opinions on whether the main two suggestions are better or worse than what we have to
deal with now.
Ah...which "main two" suggestions and what precisely is "what we have to
deal with now"? Are we talking about traditional yum+rpm? yum but on BTRFS? yum on
BTRFS but writing to a new snapshot, and then editing the bootloader configuration to make
that new snapshot available on the next boot?
The most useful thing I think is to compare *complete systems* (such as the latter vs
OSTree). It gets hard to discuss individual pieces of technology that can be combined in
many ways.
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop