On Thu, Oct 6, 2016 at 7:43 AM, Tomasz Kłoczko <kloczko.tom...@gmail.com> wrote:
> So how problem of consistent upgrade have been solved on Solaris using ZFS > and IPS? > 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 who knows. rpm-ostree integrates RPM support into OSTree. > This part is crucial. If anything wrong will happen during upgrade still > 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 of RW > 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 procedures > 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 by upstream. https://bugzilla.redhat.com/show_bug.cgi?id=864198 -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
