On Feb 21, 2014, at 5:53 AM, Colin Walters <walters(a)verbum.org> wrote:
There's also OSTree - it's a more invasive vision, as it forces *every upgrade*
to be atomic, and at present, you need to reboot.
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
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. If the upgrade implodes, the current parent tree is hosed, and if it
succeeds you have a modified active system that suggests a reboot is needed sooner than
later.
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?
Chris Murphy