Re: Technical Spec, better upgrade/rollback control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, Mar 14, 2014 at 12:16 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop

[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux