On Fri, Feb 21, 2014 at 4:51 PM, Chris Murphy <lists(a)colorremedies.com>
wrote:
I don't see this as so invasive as on Btrfs and LVM thinp snapshots,
they are COW and writes are atomic anyway. Btrfs perhaps would write
less since only changed blocks are written, while LVM thinp it's a
chunk
While a conversation about the efficiency details of BTRFS vs LVM thinp
writes versus OSTree hardlinks is interesting, it's also not very
important in the big picture.
The snapper, yum plugin (and the manually performed user) convention
is to take a snapshot that is then set aside for safe keeping and
rollback; and it is the active parent tree that's upgraded.
Yes. The downside of this is that it doesn't solve the issue where
updates actively break running processes, like say the default web
browser of the "default offering".
I think it's *utterly insane* to ship an update system that does that.
I won't continue to attach my name to one that does - instead, I will
get around at some point to researching and implementing *completely
race-free* live upgrades only *where possible*.
I'm pretty sure I'll have such a subset of live upgrades on top of a
known safe and tested basis working much faster than anyone can try to
retrofit complete safety on top of yum/rpm + snapshot tool.
But I see no reason why an implementation couldn't update the
snapshot instead of the active parent. If it fails, then clean up the
snapshot. If it succeeds, reboot when convenient. Isn't this the
OSTree convention? Create a new tree and update it, not the active
tree?
Correct. There is an important aspect here, which is that doing all of
this safely needs a system which can do *coordinated* changes to both
/boot and the root filesystem. It needs something aware of
bootloaders, kernels, as well as higher level concepts such as the
semantics of /etc and /var. OSTree is such a system.
Projects like snapper and the yum fs-snapshot plugin are basically
glued to the side of rpm (or dpkg) - they aren't in a position to
enforce reliable semantics.
For example, even though the yum fs-snapshot plugin is linked into yum,
it isn't ultimately in control of kernel installation - that's just a
shell script forked off in a %posttrans. OSTree, when installing a
kernel (or making any other change at all), will cleanly handle ENOSPC
and unwind, leaving your current system completely untouched. You
could then provision new space, and retry the upgrade.