Architecture of apply-live
应用实时架构
- Copying into an “underlay”
复制到“底层” - Package and filesystem diffs
包和文件系统差异 - Copying data for /usr
复制数据到 /usr - Updating /etc 更新 /etc
- Updating /var 更新 /var
- Tracking live state 跟踪实时状态
Copying into an “underlay”
复制到“底层”
As noted in the architecture doc, everything in rpm-ostree is oriented around creating and managing hardlinked complete bootable filesystem trees.
如架构文档中所述，rpm-ostree 中的所有内容都围绕着创建和管理硬链接完整可引导的文件系统树。
In this flow then, rpm-ostree install --apply-live strace will first create a new pending deployment, run sanity tests on it, prepare it to be booted, etc.
在这个流程中， rpm-ostree install --apply-live strace 首先会创建一个新的待部署项，在其上运行健全性测试，准备启动它等。
However, the first time apply-live is invoked, we create an overlayfs mount over /usr. It’s mounted ro from the perspective of the rest of the system, but rpm-ostree can write to it.
然而，第一次调用 apply-live 时，我们在 /usr 上创建一个 overlayfs 挂载点。从系统其余部分的角度来看，它是挂载的，但 rpm-ostree 可以向其写入。
Package and filesystem diffs
包和文件系统差异
When apply-live is invoked, rpm-ostree computes the diff between the source and target OSTree commit for /usr. If this is the first apply-live, the source commit is the booted commit. For subsequent invocations, it will be based on the current live commit.
当调用 apply-live 时，rpm-ostree 计算 /usr 的源 OSTree 提交和目标提交之间的差异。如果这是第一次 apply-live ，源提交是引导提交。对于后续的调用，它将基于当前的实时提交。
We also compute a package-level diff; this is how apply-live currently distinguishes between pure package additions versus upgrades.
我们还计算包级别的差异；这是 apply-live 目前区分纯包添加和升级的方式。
Copying data for /usr
复制 /usr 的数据
Per the core OSTree model, almost everything we care about is in /usr. So the first step is to apply the diff to the transient writable overlayfs.
根据核心 OSTree 模型，我们关心的几乎所有内容都在 /usr 中。因此，第一步是将差异应用于临时可写的 overlayfs 。
One downside is that that this diff will take extra memory and disk space proportional to its size.
其一个缺点是，这个差异将占用额外的内存和磁盘空间，与其大小成比例。
Updating /etc 更新 /etc
The second aspect we need to take care of is /etc. Normally, the libostree core handles the /etc merge during shutdown as part of ostree-finalize-staged.service, but we need to do it now in order to ensure that we get new config files (or remove ones).
我们需要关注的第二个方面是 /etc 。通常，libostree 核心在关机期间处理 /etc 合并作为 ostree-finalize-staged.service 的一部分，但我们现在需要这样做，以确保我们获得新的配置文件（或删除文件）。
Note that the changes in /etc are persistent, live-applied changes there are also hence not updated transactionally. It is hence possible for configuration files to “leak” from partially applied live updates.
请注意， /etc 中的更改是持久的，实时应用的更改因此也不是事务性更新。因此，配置文件有可能从部分应用的实时更新中“泄漏”。
Updating /var 更新/var
Normally, libostree core never touches /var. Today rpm-ostree generates systemd-tmpfiles snippets for RPM packages which contain directories in /var. In a regular update, these will hence be generated at boot time by systemd-tmpfiles-setup.service.
通常，libostree 核心从不触及 /var 。今天，rpm-ostree 为包含 /var 目录的 RPM 软件包生成 systemd-tmpfiles 片段。在常规更新中，这些片段将由 systemd-tmpfiles-setup.service 在启动时生成。
But here, we need to do this live. So rpm-ostree directly starts a transient systemd unit running systemd-tmpfiles.
但在这里，我们需要实时执行。因此，rpm-ostree 直接启动一个运行 systemd-tmpfiles 的临时 systemd 单元。
Tracking live state 跟踪实时状态
Because the overlayfs is transient (goes away on reboot), the apply-live operation also writes its state into the transient /run directory, specifically a stamp file is stored at /run/ostree/deployment-state/$deployid/.
因为 overlayfs 是瞬态的（重新启动后消失），所以 apply-live 操作也会将其状态写入瞬态 /run 目录，具体来说，一个标记文件存储在 /run/ostree/deployment-state/$deployid/ 中。
Currently, there is also a persistent ostree ref rpmostree/live-apply for the current live commit. Eventually the goal is that libostree itself would gain direct awareness of live apply, and we wouldn’t write a persistent ref.
目前，当前 live 提交也有一个持久的 ostree 引用 rpmostree/live-apply 。最终的目标是，libostree 本身将直接意识到 live 应用，并且我们不会写入持久引用。