Technical Spec, better upgrade/rollback control

[Chris Murphy]

On Feb 24, 2014, at 5:29 AM, Colin Walters <walters at verbum.org> wrote:

> On Mon, Feb 24, 2014 at 1:11 AM, Chris Murphy <lists at colorremedies.com> wrote:
> 
>> Is there good chance of optimizing OSTree to use LVMthin and Btrfs snapshots instead of hardlinks, while still being in charge of the proper semantic enforcement?
> 
> Note OSTree already today uses BTRFS_IOC_CLONE if on btrfs for implementing the separate copies of /etc.  (Actually this happens via the generic g_file_copy() since https://git.gnome.org/browse/glib/commit/?id=5eba9784979e0b723c05a45cf767046607e4e759 )
> 
> Beyond that though - because for OSTree, /usr is immutable, there isn't really a big advantage of thinp or btrfs snapshots.  Just try this right now on your laptop:
> 
> # Once for cold cache performance
> time cp -al /usr /usr.copy
> # And once for hot cache
> time cp -al /usr /usr.copy2
> 
> For me (and this a real-world RHEL7 system with a 5.1G /usr):
> 
> [root at localhost /]# time cp -al usr usr.copy
> real	0m5.199s
> user	0m0.220s
> sys	0m2.849s
> [root at localhost /]# time cp -al usr usr.copy2
> real	0m2.245s
> user	0m0.166s
> sys	0m2.049s
> 
> That's really fast enough for the use cases I envision, for now.

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).

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?


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. I'm not sure where OSTree moves old trees, how obscure the location is. Currently the way yum-plugin-fs-snapshot and snapper behave, Btrfs snapshots are placed inside the parent, so those old binaries are always available albeit in a different path. But this could be changed, and it's also possible to mount the old tree (snapshot) with noexec or nosuid mount option to avoid most?all? of this concern.

https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html


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

and later becomes a thread on both systemd and btrfs lists starting here:
http://www.spinics.net/lists/linux-btrfs/msg32361.html

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, and updating fstab properly. 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.


Chris Murphy