RFC-0005：Blobfs 快照

摘要

此 RFC 描述了一個能提高韌性的簡單快照機制 以找出升級過程中的錯誤Fuchsia Volume Manager (FVM) 異動 允許擷取 Blobfs 分區的快照，可還原至 升級期間的任何階段

提振精神

撰寫時，發生升級失敗，導致 Blobf 損毀 分區可能會使裝置處於難以復原的狀態。 復原分區目前無法還原處於此狀態的裝置， 在這種情況下，唯一支援的還原方式就是使用系統啟動載入程式， 對使用者而言不方便使用

快照機制能降低我們最後進入這個狀態的風險。

設計

基本概念是支援 FVM 內的基本快照機制 升級期間可以顯示兩個分區 可讓您在不同分區之間共用資料

目前 FVM 是一種簡單的磁碟區管理工具，能夠對應配量 從任意有片段對齊的邏輯偏移，到 並能將來自不同分區的對應分開。

Blobfs 包含下列不同的區域：

為支援這個提案，我們可以在 FVM¹。類型適用於 Slice 的「extents」：

透過上述切片類型，FVM 有可能顯示兩種 顯示 A/B 版本變化版本的範圍現在回到 Blobfs 區域則有：

在大多數情況下，只有一個分區會處於啟用狀態，而系統 會以目前的方式顯示

在升級期間，第一個分區可啟用第二個分區 分區會變成「已鎖定」，且不允許進一步寫入，但可讀取 繼續放送廣告第二個分區可能會準備 就像現在一樣 但在升級期間 系統一律會選擇返回第一個分區 保持不變

以 A/B 範圍來說，您可以輕鬆查看第一個分區的資料 preserved;第二個分區看不到第一個分區的資料。對於 日誌 (共用區域) 只有可寫入的分區 ；即第二個分區。以共用資料區域來說，點陣圖 指出可以寫入哪些區塊。凡是標示為已用到 第一個分區對兩個分區似乎都是唯讀狀態。

為了進行這項配置，第二個分區也必須具備 讀取替代點陣圖 設法知道要用到哪個區塊 因此，為了達成此目的，這可以用在邏輯位址中 使整體空間保持不變草人提出的想法是 交替的 A/B 範圍會出現在相同的偏移位置，但頂部位元集設定重疊 (唯讀)。

希望下圖說明每個分區會如何 顯示：

圖 1：分區排列方式。

注意：

• 這個簡單的 A/B 版本具備一些韌性 但不是全部
• 我們可以保留目前的漸進式更新方法 (即僅針對 發生變化的 blob) 時，可能會產生可預測的 版面配置。在使用者的建構作業中，可以選擇完全重寫 但我們仍會面對分散的環境
• 這會增加 FVM 的複雜性。

新版升級流程

您必須修改升級流程，以利建立快照互動。 目前的流程如圖 2 所示，而在 圖 3.新的 API 和互動會以彩色表示。

圖 2：目前的升級實作 (高階)

圖 3：建議採行的升級方式 (高階)

新的 FVM 作業

必須實施幾項新的 FVM 作業並整合至軟體中 推送 (SWD) 堆疊。這些 API 是用於驅動狀態機器 (圖 4)，最終會在不同分區之間切換系統。

圖 4：建立快照的狀態機器。

TakeSnapshot

將使用中的分區的中繼資料擷取至替代分區， 已清除 (請參閱「DeleteSnapshot」)。使用中的分區後 且所有後續寫入作業都必須傳送至停用的分區。

• FVM 會將使用中的分區設為唯讀。
  • 必須清除待處理的日誌項目。
• FVM 會建立無效的分區。
• FVM 會從 Active->未啟用的分區中複製中繼資料。

在這個多步驟程序中撰寫新 blob 並不會 而半寫入的 blob 就必須捨棄 只有負責寫入 blob 的元件才是 這個元件負責要求取得快照

CancelSnapshot

取消 TakeSnapshot 建立的快照填入，清除 並允許建立其他快照。

• 目前，所有對於停用分區的讀取連線都必須關閉。
• FVM 會刪除無效的分區。使用中的分區 都會重新寫入

SetWritablePartition

可寫入分區的切換按鈕。

• 此時必須清除日誌 (必須執行所有待處理的作業 完成)。上圖中的 fsync 呼叫可以促進此作業，但 在理想情況下 作業，這樣任何新寫入都無法「竊取」。

由於 TakeSnapshot 會將 但如果需要回傳資料並將其設為有效 可寫入分區 (例如為了收集未使用的 blob)，然後 才能使用這個 API

SetBootPartition

變更可啟動的分區。

一般來說，可開機的分區會根據 ZBI 運算單元 但也能單獨切換 設為可啟動。很少使用。

DeleteSnapshot

將替代分區標示為已清除。FVM 可選擇將 中繼資料

ListSnapshotPartitions

針對已設定快照的分區查詢 FVM。

QuerySnapshotPartition

查詢 FVM 以瞭解支援之分區的相關資訊 建立快照

• 識別 A/B 分區的狀態，例如使用中。

失敗模式

系統可能會從 這類機制更為快速本節說明系統判斷系統應採取哪些適當行動 就會發生錯誤

請注意，故障可能出於自願 (系統主動決定取消) 持續性的更新) 或非自願 (系統因外部因素而失敗 例如損失電源)。以上兩個情況都必須納入考量。

請注意，blobfs 設有防止中繼資料的日誌機制 在修改期間非自願性故障的情況下復原。沒有其他 需要執行工作來確保 blobf 在發生非自願性故障時， 修改內容。

在 FVM 中任何新的中繼資料作業都應進行交易， ，以防止 FVM 因非自願性故障而損毀 修改路徑。

狀態 1：TakeSnapshot 之前的狀態

在此情況下，處理失敗時不需要進行任何變更。行為 與目前的系統行為完全相同

狀態 2：TakeSnapshot 之後、重新啟動前

• 如果是自願性失敗，可叫用 cancelSnapshot API 來刪除 並將系統傳回狀態 1
• 如果是非自願性故障，系統可以決定 在重新連線 (透過叫用 cancelSnapshot) 或系統的情況下更新 可以嘗試繼續執行更新作業。

狀態 3：重新啟動後，TakeSnapshot 之前

等同於狀態 1。

支援暫時套件

臨時套件未包含在基本套件組合中 指定的系統版本

本提案對臨時套件實施一些額外限制；這個 下方「轉送新建立的檔案」一節 說明如何在任何狀態繼續支援暫時套件 另請注意，如果系統建立 新的基礎分區準備時，快照作業就會取消。

臨時套件可能在更新時仍會保留，因為 更新後，系統會將更新複製到使用中的分區 則在呼叫 TakeSnapshot 到此時間後，所有臨時的 寫入新的分區，該分區可讀取及寫入 系統 (而且更新後將成為新的有效分區) 完成)。

轉送新建檔案

決定新檔案的位置時，需考量 3 種情況 已安裝。為簡化討論，假設分區 A 處於有效狀態， 分區 B 已停用。

案例 1：TakeSnapshot 之前

• 基礎套件：未寫入。
• 臨時套件：寫入分區 A.

案例 2：TakeSnapshot 之後，重新啟動前

• 基礎套件：寫入分區 B。
• 臨時套件：寫入分區 B。請注意，這些套件 。

案例 3：重新掛接後 (NB：相當於「TakeSnapshot」之前的版本)

• 基礎套件：未寫入。
• 臨時套件：寫入分區 B。

FVM 中繼資料變更

FVM 中繼資料的結構如下：

為提升提案效率，我們需要額外的中繼資料來記錄片段 因此，您必須將下列項目儲存在某處：

enum class uint32_t SliceType {
  kNormal,
  kAB,
  kABBitmap,
  kSharedData,
  kShared,
};

struct {
  uint32_t slice_offset;  // Offset within the partition
  SliceType slice_type;   // The slice type
} extents[8];

這項中繼資料可新增至每個分區項目。更好的方法是 新增含有這項中繼資料的獨立分區 (即快照中繼資料) 分區)。未討論此中繼資料的確切位置和結構 這裡保留了實作細節

採用這個結構後，Blobfs 的範圍會是：

[
  /* super block: */       { 0,                    SliceType::kAB },
  /* allocation bitmap: */ { 0x10000 / kSliceSize, SliceType::kABBitmap },
  /* inodes: */            { 0x20000 / kSliceSize, SliceType::kAB },
  /* journal: */           { 0x30000 / kSliceSize, SliceType::kShared },
  /* data: */              { 0x40000 / kSliceSize, SliceType::kSharedData }
]

必須具有某些狀態，才能指出目前兩個分區中的哪一個 可寫入、兩個分區是否啟用 (或只有一個) 以及哪一個分區 應視為可開機⁴

您不需要對配量分配進行任何變更，但若 就必須分配替代偏移

不過，超級區塊可能需要進行其他小幅變更 (例如 該版本)。

支援 blobfs 格式的演變

本提案大幅簡化了 blobfs 格式的演變。 您可以完全刪除及重新建立替代分區，不必支付額外費用 的每次更新。

即便如此，要改進 blob 時仍需要克服兩項挑戰 格式。

• 這是共用結構，因此無法變更區塊分配對應 保持在啟用與停用的分區之間(非常簡單地分配預算 看起來是可以接受的)
• 使用中的分區無法覆寫同時分配的任何範圍 都會傳回這些 Pod不過，如果發生以下問題，就很容易解決： 某些資料的內部格式需要變更 只需配置新的範圍並移動資料 TakeSnapshot 呼叫。

實作

實作時需要進行以下變更， 取決於實際發生的變更：

1. FVM 和分區設定變更。
2. Blobfs 分配變更。
3. 早期 Bootstrap 程式碼的變更。
4. 使用新 API 的升級程序變更。

大部分的變更都必須在 #1 和 4 前完成。#1 需要在磁碟上 格式變更及遷移。還原中 也會需要乾淨安裝這是很重要的步驟 但請注意，您只需變更格式任何程式碼 新的 FVM 中繼資料可能會保持休眠狀態，直到後續階段為止。

其他步驟無需清理即可直接設定， 同樣也倒過

成效

這對效能產生輕微的影響。在升級期間 不會因快照擷取費用而受到影響 相對於其他升級活動。在其他情況下 沒有變動

聊天室需求

務必保留空間給 Blobfs 區域的額外副本：超級區塊、 Inode 資料表和點陣圖。確切時間取決於設定 但和總金額相比，應該不會太小 供 Blobf 使用。

安全性考量

無。

隱私權注意事項

無。

測試

系統將採用標準 Fuchsia 測試做法。現有的系統測試應 正在測試升級作業這些部分將擴大納入測試範圍 刻意損壞新的 Blobfs 分區和測試，試圖蓄意破壞 毀損快照分區

說明文件

FVM 的新架構和功能說明 紫紅色 >概念 >檔案系統架構。

缺點、替代方案和未知

完整 A/B 提案

還考慮到完整的 A/B 提案。雖然提案的概念很簡單 它有一些重大缺點：

• 每個分區只能使用 50% 的可用磁碟空間。
  • 我們目前對系統更新設有軟性限制， 預算限制只使用 50% 的可用 Blobfs 空間，但 A/B 使用的是 就會造成這種情況並不容易
  • 工程版本已超出 50% 的預算，因此不會 用於升級多個檔案的升級作業工程師極度仰賴 能夠執行漸進式、小幅更新因此，這個工作流程 也不是啟動條件
• 沒有在分區之間共用檔案的機制，因此 每次更新都會重寫每個檔案
  • 這代表著額外的閃光燈，而升級速度較慢。每次更新 基本上就是最大的更新

完整 FVM 快照功能

開發完整的 FVM 快照功能會面臨挑戰。傳統企業 快照機制通常是動態的，也就是說 需要更新。此外， FVM 的配量大小 (目前為 1 MiB，即將成為 32 KiB) 和 Blobfs 的區塊大小 (8 KiB)。為解決這個問題，FVM 將大幅增加 也可能造成空間不足的情況也許 開發配置的重點包括靜態對應，但在太久之前 可能會導致提案與這裡呈現的提案不一致 整體來說，這個流程可能需要更多時間 存在嚴重的缺點 (寫作放大、複雜性)，且 明顯的優勢有可能 完整快照功能長期下來將能協助 FVM 的中繼資料應提供擴充空間，以支援相關用途

既有藝術品和參考資料

安全可靠的升級功能，常解決在 方法如下：

1. A/B 副本：保留功能相同的副本，並在其間切換 這通常代表交易 不會十分要求關聯語意成本簡單，但成本高昂。
2. A/R 副本：保留一份經過簡化的復原副本， 支援還原軟體空間需求更複雜、空間需求較低 使用者體驗有些微下滑
3. A/B/R：結合 #1 &#2.
4. + 快照：在大多數情況下，只有一個副本。升級時 擷取 A 的快照，然後在快照上套用更新做為差異值 您隨時可以提供復原至快照的選項。經常 複雜但靈活有彈性

作者認為 Android 使用 #3，iOS 和 macOS 則使用 #2 &#4.

此 RFC 是 #4 的簡化版本。

解除原因

我們運用這個 RFC 持續開發數個月，之後我們決定停止 墨西哥的 RFC。此決定有幾個因素，主要是：

• FVM 程式碼集發生技術債導致進度緩慢，導致變更帶來風險。缺乏 的測試涵蓋範圍、長期錯誤，以及對 FVM 格式配置的廣泛假設 (由於缺乏 FVM 格式封裝) 是主要的阻礙。

• FVM 已經記錄不足，導致團隊難以理解。FVM 的機構知識 隨著時間的推移，初步假設 FVM 會是相對簡單的 不正確的地方建立這項功能。

• 推出這項功能所帶來的影響比最初所理解的程度還要高，因為 需要 FVM 主要格式修訂 (經判定為 會幹擾工程作業 (因為必須重構裝置， 而且還得執行 Zedboot 版本，這本身就是造成高度幹擾的作業。

有鑑於開發此功能的風險高，加上很有可能影響日益增加的 Fuchsia 開發人員社群推出這項功能已不合宜。不過，儲存空間 團隊將全力擴大測試涵蓋範圍和自動化功能，以降低風險 中所述，繼續改寫 FVM 主機工具 ( 並評估是否可能產生意想不到的複雜性 ，以減少對開發人員的影響。 已變更。