On Feb 24, 2014, at 5:29 AM, Colin Walters <walters(a)verbum.org> wrote:
On Mon, Feb 24, 2014 at 1:11 AM, Chris Murphy
<lists(a)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=5eba9784979e0b723c05a45cf767... )
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@localhost /]# time cp -al usr usr.copy
real 0m5.199s
user 0m0.220s
sys 0m2.849s
[root@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