RFC-0144:大小檢查工具

RFC-0144:大小檢查工具
狀態已接受
區域
  • 開發人員
說明

建議重新編寫 size_checker.go,打造更一致的樹狀結構內和樹狀結構外開發人員體驗。

問題
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2021-11-22
審查日期 (年-月-日)2021-12-10

摘要

本文建議開發新的大小檢查工具,並將其新增至 SDK,讓開發人員和產品負責人確認套件和產品不會超過指定的大小預算。雖然我們刻意省略實作細節,因為樹狀結構外的組件會持續改變基礎,但仍會提及設計需求和目標。

提振精神

在軟體開發期間,瞭解軟體是否符合目標的大小限制很有幫助。Fuchsia 具有大小檢查工具,可分析不同軟體群組所占用的空間,並為每個群組強制執行預算。這項工具與 fuchsia.git 的實作細節緊密相關,因此必須先結帳才能使用。fuchsia.git因此,Chromium 等 Fuchsia 消費者已實作自己的臨時方法,用於檢查軟體大小。將大小檢查工具重新編寫為 ffx 外掛程式,並新增至 Fuchsia SDK,即可統一在 Fuchsia 軟體上強制執行大小預算的方法,方便日後的開發人員開始使用 Fuchsia。

利害關係人

誰會受到這項 RFC 是否通過的影響。

協助人員:

  • Hunter Freyer (hjfreyer@google.com)

審查者:

  • Saman Sami (samans@google.com) - 功能
  • Anthony Fadrianto (atyfto@google.com) - 與基礎架構整合
  • Sébastien Marchand (sebmarchand@google.com) - 與基礎架構整合
  • Rohan Pavone (rohpavone@google.com) - 與 Chromium 整合
  • Amit Uttamchandani (amituttam@google.com) - Integration into ffx

已諮詢:

  • Aaron Wood (aaronwood@google.com) - Assembly Integration

社交:

這個專案已事先以內部文件形式發布,並在會議中與利害關係人討論。在草擬這份 RFC 之前,我們已收集相關需求。

背景

本 RFC 假設您瞭解下列主題。

兩種大小檢查方式

大小檢查可分為兩類:

  1. 刷機時,圖片不會超過目標分區大小。
  2. 更新期間,Blob 會符合 FVM 預算。

刷機:開發人員可以將新映像檔刷入 Fuchsia 目標裝置。刷入映像檔時,分割區的內容會完全由新映像檔的位元組取代。為確保順利完成刷機,新映像檔的大小不得超過分割區大小。

更新:Fuchsia 目標可以無線下載更新。為確保更新成功,Blob 占用的總空間不得超過 FVM 設定的預算。通常 FVM 中的空間會保留給 UpdatePackage 和其他 Blob,因此工具無法直接填滿 FVM,然後檢查最終映像檔是否符合分割區。

目前工具

Fuchsia 提供兩種工具,協助檢查大小:

  • size_checker.go
  • blobfs-compression

size_checker.go

連結至來源

這項工具可在樹狀結構內 (fuchsia.git 內) 使用,確保 Blob 符合預算。size_checker.go 會判斷 Fuchsia 存放區中 Blob 目錄的壓縮和對齊大小,預算可依產品定義,但目前不會用於 fuchsia.git 中的任何產品。由於這項工具會檢查 fuchsia.git 中的目錄,因此必須先結帳 fuchsia.git,才能使用這項工具。

首先,Fuchsia 建構作業會產生 blobs.json 檔案,列出 blobfs 中每個 Blob 的壓縮和對齊大小,以及 blob.manifest 檔案,列出這些 Blob 的 Merkle 和來源路徑。

接著,系統會執行 size_checker.go 並完成下列動作:

  1. 讀取 blobs.json,收集每個 Blob 的壓縮大小: compressed_size
  2. 讀取 blob.manifest 以收集所有套件。
  3. 計算套件中包含 Blob 的次數: share_count
  4. 計算每個 Blob 的共用大小:shared_size = compressed_size / share_count。由於多個預算可能包含相同的 Blob,我們會使用 Blob 的 shared_size,在各個預算之間平均分配大小用量。
  5. 建構 N 元總和樹狀結構,代表建構輸出內容中每個目錄所消耗的空間,方法是在 Blob 路徑的節點中加入每個 Blob 的 shared_size
  6. 逐一疊代每個預算,並確認目錄的預算大小大於所耗用的空間。
  7. 在預算中逐一疊代每個非 blobfs 套件,使用 blobfs-compression 計算 Blob 大小的總和,並確認總和在預算範圍內。
  8. 列印結果。

加總樹狀結構

blobfs-compression

連結至來源

這項工具可以估算一組 Blob 的壓縮和對齊大小,但並非 100% 準確,有時可能會高估 Blob 的大小。這項工具絕不會低估 Blob 的大小。

blobfs-compression 會透過 Fuchsia SDK 傳送給用戶端,目前是 fuchsia.git 以外唯一可估算為 Fuchsia 建構程式碼大小的方法。Chromium 是這項工具的用戶端。

目前工具的問題

  • 檢查套件大小的 In-Tree 和 Out-Of-Tree 方法是不同的工具。
  • 這兩項工具都無法直接檢查圖片大小,確保順利完成刷機。
  • size_checker.go
    • 未記錄。
    • 取決於 Fuchsia 建構的實作細節,這並非穩定合約。
    • 無法在樹狀結構外運作。
  • blobfs-compression
    • 無法保證傳回 Blob 的正確壓縮大小。
    • 在 Blob 層級運作,不如在套件層級運作實用。開發人員會以套件為單位,將軟體新增至產品。
    • 沒有標準輸出格式,因此不容易編寫指令碼,自動化使用方式也不穩定。

需求條件

  1. 在 SDK 中提供可在樹狀結構內和樹狀結構外運作的工具。
  2. 工具支援目前工具的所有現有用途。
  3. 這項工具可執行兩種尺寸檢查:
    • (a) 圖片
    • (b) 一組套件中的 Blob
  4. 在情況 (2) 中,系統會對所有集合中的所有套件執行 Blob 重複資料刪除作業。
  5. 如果超出使用者指定的預算,工具會傳回失敗訊息。
  6. 這項工具可與其他 SDK 工具(例如 Image Assembler (RFC-0072)) 完美搭配使用。
  7. 這些工具可輕鬆用於指令碼,並提供可剖析的輸出內容,以及 Gerrit Size Plugin 使用的輸出內容。
  8. 工具的使用方式和架構將記錄在 fuchsia.dev 中。

設計

一致的開發人員體驗

我們將以 Rust 編寫新的 ffx 外掛程式,執行兩種大小檢查。根據 CLI 評量表,最好將其併入 ffx,以鼓勵共用工作流程,並提高可探索性。此外,我們偏好擴充現有檔案格式,而非發明新的格式。

可編寫指令碼

這個工具主要用於建構系統,因此輸出內容應可剖析。輸出格式可能會使用 json5 做為輸出格式,但隨著 Assembly 專案的進展,可能會考慮使用其他格式。

圖片大小

建構 Flash 資訊清單時,應同時執行圖片大小檢查工具,將組裝的圖片對應至分割區。目前,閃爍資訊清單是在 Fuchsia 建構系統中建立,因此 ffx 外掛程式會透過 GN 動作叫用。日後可能會提供 SDK 工具,用於建構 Flash 資訊清單,而我們的尺寸檢查工具應能以 ffx 外掛程式的形式,在該情境中順暢運作。

如要測量圖片大小,只要開啟檔案並讀取中繼資料中的長度即可。這項功能適用於任何未壓縮或稀疏的圖片。舉例來說,這個方法不適用於稀疏 FVM,而且目前沒有任何程式庫可計算稀疏 FVM 的擴展大小,因此工具會忽略稀疏 FVM 的大小檢查。

套件大小

Blob 和套件大小檢查應與組裝密切整合,因為工程師會在組裝期間將套件分組為集合,並合併這些集合來指定產品。

大小檢查工具會使用 blobs.json 檔案,列出每個 Blob 的壓縮和對齊大小。開發人員可以提供多個 blobs.json 檔案做為工具的輸入內容。如果系統在提供的任何blobs.json檔案中都找不到套件的 Blob,大小檢查工具就會使用 blobfs 工具,為所有遺失的 Blob 生成單一 BlobFS 映像檔,並額外生成 blobs.json。尺寸檢查工具會讀取產生的 blobs.json,取得缺少的 Blob 大小。

與現有的 size_checker.go 工具類似,新的大小檢查工具會將每個 blob 的大小除以使用該 blob 的套件數量,計算出每個 blob 的共用大小。這項共用大小就是預算編列時所用的值。

實作

這項工具的導入和整合作業將分階段完成。

  1. 為套件組合宣告預算。請參閱下方的說明
  2. 編寫 ffx 外掛程式,確保套件組符合預算
  3. 請確保 ffx 外掛程式的輸出內容與建構系統中先前工具的輸出內容相符。如果輸出內容不同,建構作業應會失敗。請參閱下方的說明
  4. 宣告圖片的預算
  5. 新增功能,確保圖片大小符合預算
  6. 停用 size_checker.go,並讓新的 ffx 外掛程式承擔負載
  7. 刪除 size_checker.go 程式碼。

產生預算檔案

為避免維護特定產品的兩組相同預算,建構系統將更新為讀取現有的 size_limits.json 和組件 產品設定,並產生新的預算檔案。系統會剖析產品設定,收集每個套件資訊清單,並根據 size_limits.json 中設定的目錄預算分類這些資訊清單。

預算檔案格式可能如下:

[
    {
        name: "name-of-package-set",
        packages: [
            "path/to/manifest1.json",
            "path/to/manifest2.json",
        ],
        budget_bytes: 12000,
    },
]

新的大小檢查工具可承受建構作業的負載後,產生的預算檔案就會簽入存放區,產生的程式碼則會刪除。

輸出比較

在轉換至新版大小檢查工具期間,建構系統會確認新工具的輸出內容與舊工具的輸出內容相符。系統會編寫指令碼,剖析這兩項工具的輸出內容,並確保每個套件群組 (或目錄) 的預算和計算出的用量相等。為關聯這兩種輸出格式,指令碼會假設用於識別套件集的名稱相同。由於舊版和新版工具都使用相同的基礎機制計算 Blob 大小 (使用 blobfs),因此計算出的用量也會相同。

效能

大小檢查工具適用於建構系統,因此相較於網路堆疊等項目,對效能不穩定性的容許度較高。另一方面,縮短建構時間對提升開發人員生產力至關重要。 此外,這個工具位於建構的關鍵路徑上,因為它必須等待所有套件建構完成,並組裝映像檔,才能開始執行,因此無法平行化。

目前的 size_checker.go 工具執行時間約為 1 到 2 秒,新工具的執行時間應與此相近。

人體工學

請參閱「設計」一節。

回溯相容性

這項設計不需要回溯相容。

安全性考量

這項設計不會造成任何安全性問題。

隱私權注意事項

這項設計不會對隱私權造成影響。

測試

在 Fuchsia 建構版本中,新的大小檢查工具會與 size_checker.go 一併執行,並比較輸出內容,確保兩者具有相同的預算和計算空間消耗量。

隨著工具新增功能,也會編寫單元測試。

說明文件

說明文件將新增至 fuchsia.dev

缺點、替代方案和未知事項

但有幾種替代方案不太理想。

不採取任何行動:這會要求用戶端自行建立臨時方法來完成大小檢查,但隨著用戶端群組增加,這種做法無法有效擴展。

重構現有工具size_checker.go可以重構為支援樹狀結構外的項目。根據 CLI 評量表,建議將公開工具新增至 ffx,以利共用工作流程及提升探索體驗。此外,重構現有程式碼所需的變更幅度過大,實際上完全重寫工具反而更省事。

使用 blobfs-compression:如要計算每個 Blob 的壓縮和對齊大小,可以使用 blobfs-compression 工具,不必產生新的 blobfs 映像檔。這個替代方案的主要缺點是,無法保證 blobfs-compression工具能準確壓縮或對齊。具體來說,blobfs-compression 工具會假設為非緊湊型 Merkle 樹狀結構,因此產生的 Blob 大小通常會大於實際情況。此外,blobfs-compression 工具一次只能測量一個 Blob,因此使用起來較為麻煩,且可能比執行一次 blobfs 工具還慢。生成 blobbf 圖片更符合目前的 size_checker.go,也更準確。

既有技術和參考資料

請參閱「背景」一節。