On Thu, Oct 6, 2016 at 7:43 AM, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
So how problem of consistent upgrade have been solved on Solaris
ZFS has ability to create snapshot of the vol (RO resource) and create on
top of the shapshot clone (RW resource).
Whole upgrade process consist from few steps:
- find volumes which needs to be snapshoted and cloned
- create clones
- mount clones as separated tree and perform upgrad
This is what OSTree is effectively doing now.
/usr is read only. And updates aren't ever applied to the current file
system tree. A new tree is created and updated, the bootloader
configuration is changed, and the system is rebooted (at the user's
leisure) to get the updated system. i.e. it makes it clear your system
is not running updates until it's rebooted, which it maybe probably
rpm-ostree integrates RPM support into OSTree.
This part is crucial. If anything wrong will happen during upgrade
working system is not affected. It is possible to observe state of broken
upgrade and produce very precise diagnostic data allowing to fix upgrade
process on layer of packages. In other words impact of during upgrade on top
of still working system is NULL/ZERO!!!
Yes, it's the same for rpm-ostree, i.e. the basis for the various
Atomic Host products Fedora creates. And there's going to be a
Workstation version of it for Fedora 25 (for very early adopters, it
won't be at getfedora.org
On Linux at the moment is available btrfs which provides possibility
snapshots (equivalent of ZFS clones). All what needs to be added to this
layer is btrfs volume attribute indicating that volume needs to be cloned
during upgrade in case of more complicated scenarios.
It's actually kinda complicated to handle the changes that occur from
the time the current tree is snapshot, the update and reboot happens.
The current root tree can have changes to /var and /etc happening
during the update and before reboot, so those need to get merged such
that you can reboot either the old or new tree and have log and
journal continuity, and so on. rpm-ostree does this.
Another small bit which needs to be sorted is related to install
implemented in anaconda and post installation procedures in kernel package.
What is missing here? anaconda does not allow now to use /boot on btrfs. It
forces use ext3/4.
It's a grubby bug. It doesn't understand Btrfs subvolumes. Any brave
person who wants to fix grubby? Someone else already tried, so there's
code available to look at to help grok the logic of what needs to be
done; but needs to be implemented in a different way to get approved