Technical Spec, better upgrade/rollback control

[Chris Murphy]

On Feb 21, 2014, at 5:53 AM, Colin Walters <walters at 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