垃圾回收 (GC) 是从设备中移除“不必要”blob 的过程。执行该操作通常是为了释放磁盘空间,以便可以解析新的临时软件包,或执行 OTA(在内部使用软件包解析)。
触发方式
GC 由 pkg-cache 实现,后者通过 fuchsia.space/Manager.GC 提供功能。
可以通过运行 fx shell pkgctl gc
手动触发。
它会在 OTA 期间的各个点由系统更新自动触发(如有必要)。
更新检查工具会由工程 build 使用的更新检查工具 system-update-checker 自动触发(如有必要)。
算法
当前算法基于 Open Package Tracking RFC 建议的设计。
定义
- 基础软件包
- “base”或“system_image”软件包(通过启动参数中的哈希标识)以及其
data/static_packages
文件中(通过哈希)列出的软件包。 - 通常是指运行特定配置所需的最小软件包集。
- “base”或“system_image”软件包(通过启动参数中的哈希标识)以及其
- 缓存软件包
- “base”软件包的
data/cache_packages.json
文件中列出的软件包(按哈希值)。 - 从概念上讲,我们希望在没有网络连接的情况下使用软件包,但仍希望能够选择临时更新。
- “base”软件包的
- 开放软件包
- pkg-cache 当前提供软件包目录的软件包
- 写入索引
- 目前在解析过程中编写 blob 的软件包
- 保留的索引
- 软件包 blob
- 软件包所需的所有 blob。
- alt.far 和内容 blob,以及所有子软件包的软件包 blob,以递归方式进行。
- 根据这一定义,保护软件包免受 GC 保护,可保护其所有子软件包。作为软件包本身,子软件包本身不一定会独立于超级软件包提供的保护而受到保护。
实现
- 如果当前启动分区未标记为运行状况良好,则失败,以避免在发生回退时删除上一个系统所需的 blob
- 确定所有常驻 blob 的集合,
Br
- 锁定写入索引和保留索引
- 确定所有受保护的 blob,即以下所有软件包的软件包 blob:
Bp
:- 基础软件包
- 缓存软件包
- 打开软件包
- 编写索引软件包
- 保留的索引软件包
- 删除集合差异
Br - Bp
的 blob - 解锁写入和保留索引