原子更新调研分析（二）deepin原子更新调研开发
deepin的原子开发告一段落，项目已经交给社区维护，仓库在：https://github.com/linuxdeepin/deepin-upgrade-manager。预计写几篇文档记录下开发的细节与初衷，算是对这个项目的总结叭。
原子更新是什么
原子更新是对deepin系统级别的备份方案，为什么叫原子更新呢？原子说明本次操作是不可中断的，连一起意思就是本次系统更新是可靠的，可逆的，不可中断的意思，旨在解决deepin的系统更新不稳定的问题，若存在系统更新崩溃可随时回到之前备份的任意节点，保证系统数据。
老版本存在问题
- deepin在v20以及v20之前，在系统备份的时候使用的都是ab分区。ab分区的劣势主要是只能支持全盘分区的，像自定义分区的就无法支持，并且只能备份一个版本，有时候a,b版本的备份内容都存在问题时就很棘手，无法找到之前版本了。
- ab备份的时候，全盘安装的时候会多一个分区来存储系统文件，当时的主分区无法调整，就是因为ab分区需要空间太大了这个原因，如果主分区是要30g空间，那个备份分区也需要30g,会对磁盘空间有较大浪费。
- 备份时间较长，在ab分区的时候，需要将主分区内容全部拷贝到另一个分区，如果是机械磁盘，耗费的时候就是非常长的了。
原子更新优势
- 可以备份任意版本，多个数量系统版本
- 由于是增量备份，所以备份速度较快，回滚也较快，占据空间较小。
原子更新劣势
- 与debian的管理包应用的软件耦合较低，无法做到像rpm-ostree对每一个应用进行备份管理。
- 由于第一个原因，所以备份的时候需要对系统进行一个文件校验，查询每次安装应用后增加的应用，有时间消耗。
未来展望
- 希望与系统耦合增加，能明确知道每次应用更新内容
- 增加只读根分区功能，通过原子更新来组成os进行系统更新
- 系统更新应该是一个阻塞功能，用户不能进行对系统进行操作，类比windows/手机的系统更新。
- 改造ostree,当前ostree是单线程，原子更新备份与回滚是为阻塞操作，可以将其改造为多线程操作。
实现原理简介
原子更新的具体实现在github上的概要设计，这里简单讲一下，并把一些遇到的困难点记录一下。原子更新由于是系统级别应用，需要尽可能减少依赖，所以使用go开发，主要分层如下图：
- 其中deepin-boot-kit是管理grub显示更新，原子更新的grub引导项展示由此模块支持，后期可以讲一下这个模块以及grub原理。
- 原子更新支持命令行与dbus两种方案的调用，dbus则为通用接口，命令行则为了在initramfs下使用。
- 用户可以使用 commit,init,rollback,version的直接命令调用原子更新
- 原子更新内部则封装ostree的命令，实现底层接口，后期ostree也可以换其他的文件级别的备份方案。
开发困难点
- 自动选择最大分区
- 断电回滚，重启后继续回滚
- 引导分区的加密
- 提交时快速找到系统增量文件，提交至ostree仓库
- 回滚时，快速建立rootfs对系统进行替换