Chapter 2. Concept

Table of Contents

2.1. Filesystem
2.2. Updating the correct snapshot
2.3. Workflow
2.4. Simplified workflow

2.1. Filesystem

This chapter describes the handling of the root file system, i.e. the core functionality of transactional-update. Of course not all information (such as /var or /home) should be stored on the root volume, see Chapter 3, System setup for a real world setup.

transactional-update is based around several concepts of the Btrfs file system, a general purpose Copy-on-Write (Cow) filesystem with snapshot and subvolume support. Subvolumes look like a directory, but behave like a mount point. They can be accessed from the parent subvolume like a directory, or they can be mounted on other directories of the same filesytem. Snapshots will be created from existing subvolumes, excluding other subvolumes inside of it, and are read-only by default.

Implementation note: transactional-update may also be implemented for any other file system as long as it provides snapshot functionality and the ability to boot from snapshots. See Chapter 5, Porting to other systems for requirements and porting information.

2.2. Updating the correct snapshot

transactional-update is using zypper with the --root option pointing to the new snapshot for package management. Other commands (such as the creation of initrd) will be called with chroot.

2.3. Workflow

List of snapshots

At the beginning, there is a list of old snapshots, each one based on the other one, and the newest one is the current root filesystem.

List of snapshots with new read-only Clone of current root filesystem

In the first step, a new read-only snapshot of the current root filesystem will be created.

List of snapshots with a read-write Clone of current root filesystem

In the second step we switch the snapshot from read-only to read-write, so that we can update it.

List of snapshots with a read-write Clone of current root filesystem, which will be updated with zypper.

In the third step the snapshot will be updated. This can be zypper up or zypper dup, the installation or removal of a package or any other modification to the root file system.

List of snapshots with the clone again read-only.

In the fourth step the snapshot will be changed back to read-only, so that the data cannot be modified anymore.

List of snapshots with the read-only Clone the new default.

The last step is to mark the updated snapshot as new root filesystem. This is the atomic step: If the power would have been pulled before, the unchanged old system would have been booted. Now the new, updated system will boot.

List of snapshots with the current root filesystem as newest at the end.

After reboot, the newly prepared snapshot is the new root filesystem. In case anything goes wrong a rollback to any of the older snapshots can be performed.

List of snapshots with a read-write Clone of current root filesystem, which will be updated with zypper.

If the system is not rebooted and transactional-update is called again a new snapshot will be created and updated. This new snapshot is based on the current running root filesystem again, not on the new default snapshot! For stacking changes (i.e. if several commands are supposed to be combined in one single snapshot) the shell command can be used to perform any number of operations.

2.4. Simplified workflow

In essence the logic of transactional-update can be summarized as follows:

  • SNAPSHOT_ID=`snapper create -p -d "Snapshot Update"`
    	  
  • btrfs property set ${SNAPSHOT_DIR} ro false
    	  
  • zypper -R ${SNAPSHOT_DIR} up|patch|dup|...
    	  
  • btrfs property set ${SNAPSHOT_DIR} ro true
    	  
  • btrfs subvol set-default ${SNAPSHOT_DIR}
    	  
  • systemctl reboot