BLOB-Based Atomic Remounting for Operating System Image Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing operating system updates often result in instability due to mixed versions of software packages, leading to random failures and requiring manual fixes or system reboots, which cause downtime.
Innovation Solution
Performing atomic live updates using binary large object (BLOB) files, where the update is completed only if all software packages are successfully installed, and reverting back to the previous version if not, while continuing unaffected services and avoiding reboots.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional sequential software package installation is used, then updates can be applied, but system instability occurs due to mixed versions of software packages
Solution Approach 1:
The operating system image is divided into multiple read-only layers (existing OS image layer and update package layer) that are stacked together. This segmentation allows the update to be applied as a separate layer without modifying the existing OS, preventing version mixing and ensuring update consistency while maintaining system stability.
Solution Approach 2:
The update package layer is prepared and validated before being applied to the running system. All update files are staged in a read-only layer first, and only after successful validation is the layer activated. This preliminary action ensures that incomplete or inconsistent updates cannot be applied, preventing system instability.
2Manufacturing precision
If A/B deployment of updates is performed, then update consistency is maintained, but system downtime occurs due to required reboots
Solution Approach 1:
The update layers are designed to be mounted and activated without requiring system reboot. The file system continuously serves requests from the appropriate layer (existing or updated) based on mount status, allowing the OS to remain running and services to continue operating throughout the update process, eliminating downtime while maintaining update consistency.
Solution Approach 2:
A file system layering mechanism acts as an intermediary between the update packages and the running operating system. This intermediary layer allows updates to be applied and activated without interrupting the OS execution, serving as a mediator that enables continuous operation while still implementing consistent updates.
3Loss of time
If operating system updates are performed live without rebooting, then downtime is reduced, but system instability increases due to mixed software package versions
Solution Approach 1:
Different parts of the file system are assigned different qualities: the existing OS image layer is read-write and mutable, while the update package layer is read-only and immutable. This local quality distinction ensures that updates cannot be partially applied or corrupted, maintaining system stability even during live updates without reboot.
Solution Approach 2:
Update packages are fully validated, staged, and prepared in a read-only layer before activation. This preliminary preparation ensures that only complete and consistent update sets can be applied, preventing the mixed version states that cause instability during live updates.
Data Source
AI summary
Techniques for atomic live updates to operating systems are described herein. For example, a computing system can generate a first version of a binary large object (BLOB) file indicating first metadata for each file of a first version of an image for an operating system. The computing system can generate a second version of the BLOB file indicating second metadata for each file of a second version of the image. The second version can include new files associated with an update to the operating system. The computing system can execute the update to the operating system by remounting, by a file system for the operating system, the second version of the image of the operating system using the second metadata of the second version of the BLOB file.