[sle-beta] Transactional Updates in Leap 15

Thorsten Kukuk kukuk at suse.de
Thu Apr 5 06:38:51 MDT 2018

On Thu, Apr 05, Joe Doupnik wrote:

>     The referenced doc is interesting to read and think about. Alas,
> patching nirvana is still on back-order.
>     My thinking (yours will likely vary) is as follows. The snapshot-like
> temp area can be as large as the main o/s file system (root) because we put
> more into that area than just the o/s and we try to avoid over partitioning
> etc. Of particular concern is the arrow of time, which means changes occur
> on the running system after snapping and where also patches will eventually
> appear. Thus the snapshot becomes out of date after the first such change to
> the running system. Think about databases, linked systems, memory cached
> data and the like. Thus a snapshot may not be a safe item to restore in many
> cases.

Please show me a database, which can write to a read-only filesystem ;)
Since we work with a read-only root filesystem, you have to strictly seperate
data from applicatons, and only the applications are part of the snapshot.
So you will never loose data.

>     What makes more sense to me is patch a quiescent system. That would mean
> accumulate the new change sets and then bring up the system in memory based
> rescue mode where the regular file systems is/are otherwise not enabled. The
> scheme then tries applying patches one by one (with a log to revert), and if
> a failure occurs then consider undoing them all, with optional variations
> about accepting some regardless and so forth. This eliminates concerns about
> open files, memory caches, partial transactions, interaction amongst
> machines, huge extra disk space, not being restricted to BTRFS, and likely a
> few more nuances. It also avoids yet another installation-time-only option
> and thus can be used well after a machine has been built in an ordinary
> manner.

Your approach is what we offer today, but this does not solve any of the
problems we solve with transactinal-updates. Especially not the problem
of a very long downtime of the machine and services for big updates.


Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

More information about the sle-beta mailing list