| RFC-0257：storage-host：將上層儲存驅動程式的元件化 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 將上層儲存體驅動程式 (GPT、FVM 等) 移至新的儲存空間主機元件。 |
| 問題 | |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-07-08 |
| 審查日期 (年-月-日) | 2024-08-13 |
摘要
目前，區塊裝置是以分層方式透過驅動程式架構來實作
。會實際與硬體互動的低階驅動程式 (例如 sdmmc、
virtio) 實作內部 fuchsia.hardware.block.driver 通訊協定，且
高階驅動程式 (例如 GPT、FVM、zxcrypt) 會與這個通訊協定互動
提供更高層級的功能
fuchsia.hardware.block 和 fuchsia.hardware.block.partition 通訊協定)。三
提議將所有上層區塊驅動程式移至新元件，
storage-host：只將低階驅動程式在驅動程式架構中。
提振精神
這項變動的主要目標在於將儲存空間堆疊與 Devfs 分離， 驅動程式庫驅動程式架構 Devfs (更廣泛地將驅動程式庫堆疊遷移至驅動程式架構 V2)。
目前儲存空間堆疊大多仰賴 Devfs 的探索與 透過拓撲來封鎖裝置移除這個依附元件需要 大量重構儲存空間堆疊，以使用替代方案 Devfs 的一種機制 (在本文撰寫本文件時， )。由於您必須建立新的 API 和儲存空間堆疊 需要改變才能使用；現在正是重新思考 實際實作這些 API
可說的是，高層區塊裝置 (如 GPT) 並非 真正意義也不會與硬體互動 層層封鎖裝置換句話說，驅動程式庫架構經過最佳化調整 用途與高階封鎖裝置不同儲存空間堆疊則包含 一直都是駕駛架構的異常用戶端 (例如， 也似乎沒有 讓駕駛人架構或儲存團隊 不相符。
除了加速推動驅動程式架構團隊為 Devf 帶來的改變之外， 將先前的層層遷移之後，還有許多其他好處 封鎖裝置到儲存空間主機：
- 透過簡化與加快儲存團隊的工程速度 將技術堆疊整合至熟悉的語言 (Rust) 和架構 (一般非驅動程式庫元件)
- 啟用需要跨堆疊工作的效能最佳化 (例如， 也可能使用 API 搭配上層區塊驅動程式或 API 例如 I/O 優先順序所需的變更)
- 讓儲存團隊能掌控要存取哪些元件 封鎖裝置，應依儲存空間政策進行中介服務 (而非存取權 /dev/class/block)。
- 我們會將這些驅動程式轉攜至驅動程式架構第 2 版，
相關人員
講師：
- hjfreyer@google.com
審查者：
- garratt@google.comm
- csuter@google.com
- curtisgalloway@google.com
- surajmalhotra@google.com
諮詢：
- 也諮詢了駕駛架構團隊。
社交功能：
此 RFC 早就已經與驅動因素架構團隊進行交流， 出版品
需求條件
這項變更必須明確告知 Fuchsia 的其他部分；也沒有任何功能 持續進行相關變更
這項變更並「不」會在效能上造成任何重大迴歸 例如記憶體或儲存空間用量
設計
Storage-host 元件將管理分區和巢狀區塊裝置 以及實體區塊裝置會在 Rust 中實作。
為方便說明，本程序描述啟動流程為具有下列特性的系統： GPT 格式區塊裝置Storage 主機將可處理其他 MBR 和 FVM 等分區架構。
Fshost 目前正在監聽驅動程式架構中的區塊裝置，並偵測
並決定要繫結至哪個區塊裝置的驅動程式庫。例如：
fshost 會啟動 gpt 裝置驅動程式，
。對 fshost 中的不同
gpt 裝置驅動程式庫，但 fshost 會改將裝置交給儲存空間主機。
storage-host 會從 GPT 剖析分區表，並匯出一個
每個分區的 fuchsia.hardware.block.partition.Partition 服務。這些
您會在由 Cloud 服務匯出的「partitions」目錄中使用這項服務
storage-host這個目錄可以取代 dev-topological
來自 Devfs 的路徑，允許階層式的探索與存取
多個分區
Fshost 會監控發布至「partitions」的裝置，並照常運作
比對，可能包括啟動檔案系統。巢狀分區有效
(例如 GPT 中的 FVM)。在本範例中，fshost 會直接要求 storage-host
掛接及解開特定分區。
檔案系統和其他用戶端用來執行區塊 I/O 的通訊協定 必須變更元件，因為 storage-host 會 驅動程式採取的通訊協定儘管如此，我們可能會選擇 其他原因，例如提升效能。
目前使用 Devfs 探索並連結區塊的用戶端
裝置需要攜碼轉移至使用 partitions。因為很多使用情況
指揮官，分區映像檔安裝工具
就相信長遠來說是合理的
讓客戶透過 fshost 使用中介服務存取功能，因此我們能更精細地控管
封鎖應用程式的使用時間舉例來說，我們可以向 fshost 公開 API
而非授予所有區塊存取權
裝置。partitions 目錄只會用於樹狀結構內，且應包含
且我們能根據需要彈性調整
fshost 和 Storage-host 之間的往返關係 (舊稱「Fshost」) 從區塊裝置到 Storage 主機， storage-host 會繫結至分區和傳遞 後置巢狀區塊裝置，到 fshost 中) 看起來可能不尋常，但 好處實際上，這項技術能加快 Storage 主機的實作速度， 極少數需要調整 fshost也會將 負責任：fshost 導入儲存政策 (要繫結檔案系統、 會阻擋要掛接的裝置等) 而 Storage 主機則可協助您 政策。循環關係可以是 之後再重建。
請注意，早期啟動不會有任何變更，也就是將啟動啟動檔案系統從 ZBI。這部分的啟動順序位於啟動 fshost 之前 未變更任何狀態
多個儲存空間主機執行個體
雖然目前不需要，但我們會避免以那些假設 系統中有一個儲存空間主機執行個體。舉例來說，我們 您需要為嵌入式儲存裝置和 可插入式 USB 裝置，以維持 儲存空間堆疊，以強化安全性或者，我們可能會請 執行不同格式的 Storage 主機執行個體，例如GPT 和 FVM 和隔離機制
圖 1：目前架構。
圖 2：建議架構。
實作
這項異動可以在遷移期間逐步執行，並以各階段的方式變更。 各種驅動因素
例如，vim3 設定只需要遷移 GPT 驅動程式庫 我們可以先導入這個方法，然後在產生 GPT 驅動程式庫後 在 vim3 上啟用 storage-host 已攜碼轉移。智慧型產品需要 FVM 和 zxcrypt。這些都是 。
我們必須確保用戶端 可以是 devfs 或 storage-host，就像我們計劃使用 探索功能類似的目錄導向介面
我們會在 fuchsia.fshost.StorageHost限制儲存空間主機的用量
並在特定產品/開發板上啟用
設定準備完成。
在所有使用情況轉移完畢且系統穩定後，我們 完成遷移作業的相應邏輯。
storage-host 會實作為單體 Rust 二進位檔。如果 例如為了減少二進位檔案過度，我們可以將功能獨立出來 (例如 zxcrypt) 傳入程式庫，並視需要在 不過，為了方便起見，我們一開始會先採用 單體二進位。
請注意，由於儲存空間主機和 對等的驅動程式架構實作，這些變更可以安全地進行 問題也會還原。
請注意，FVM 和 GPT 也提供多種代管工具，三 不打算將這些物件移植到 Rust，因為這類測試是穩定，與 ，目前並沒有理由變更這些因素。
成效
我們認為，這項異動會影響效能，但前提是： 而且不必依賴 FVM 和 zxcrypt雖然現在 這個元件可以拿出 藉由一些簡單的 API 變更 (例如 storage-host 可以代理視窗檢視畫面) 傳送給檔案系統，檔案系統就會 與基礎區塊驅動程式庫直接通訊)。
針對 FVM 和 zxcrypt，storage-host 必須攔截並修改每個要求 所以相較於目前的 驅動程式架構實作。對 FVM 來說，這是對應虛擬機器 偏移值，而 zxcrypt 則需要加密。
延遲時間會增加，因為系統必須從 區塊 FIFO (由儲存主機取代)，並在基礎 FIFO 重新加入佇列。請注意， 驅動程式架構實作仍需要攔截、修改和重新排入佇列 但驅動程式庫對驅動程式庫通訊是透過 Banjo 進行 通訊協定 (fuchsia.hardware.block.driver.Block) 優先使用更有效率的通訊協定 兩位駕駛人在同一處使用運輸機制。也就是說 也會因額外程序透過 Storage 主機躍點而產生延遲時間。
我們認為有幾種方式能解決這個問題 (讓問題變得更簡單或可行) 使用 storage-host)：
- 更容易在 Rust 中引入並行，因此我們可以改善 以管道處理或平行處理工作量來分配處理量
- Blobfs 使用外部解壓縮程式來提高安全性，其中 讀取檔案讀取的來回傳輸。這可以移至 Storage 主機，並在 與 I/O 要求相輔相成，取消 storage-host(從安全性的角度來看，Blobfs 不會太糟糕了。 那麼 Blobfs 並不會假設區塊裝置本身是 值得信賴；就安全性層面而言，這主要是避免在流程中 可能會破壞 Blobfs 程序。其他檔案系統 換句話說，Minfs 沒有與 Blobfs 驗證資料相同的能力，因此 儲存空間主機遭入侵時，可能會遭到竄改我們需要測量 以便對這項最佳化作業產生效能和安全性的取捨)。
未來，我們期望能更輕鬆地在 Google Ads 中 storage-host，以便我們進行日後的效能最佳化工作。適用對象 例如，我們最終可能需要引進 I/O 優先事項 整個堆疊中的各項變更這樣一來，Storage 就能更輕鬆地 將程式碼集整合至程式語言與環境，可大幅提升作業速度 。
回溯相容性
由於我們只修改樹狀結構內程式碼和 API，因此沒有反向程式碼 可能影響到這項變革的相容性問題
安全性考量
重新執行 zxcrypt 需要通過安全性審查，因為這是 安全機密服務
此舉將透過以下幾個方式加強安全性：
- 系統會在 Rust 中實作驅動程式 (而非 C++)，藉此減少記憶體 安全漏洞。
- 我們將有機會透過以下方式稽核並減少使用者存取裝置的權限： /dev/class/block 或 dev-topological，因為上述所有用法都必須是 已遷移。
請特別注意，本提案將會對 現有的安全性網域您可以考慮採用 託管於與單一安全性網域相同的程序；入侵 一個意味著可入侵另一個與各項元件通訊的元件 其他 FIDL 或其他處理序間通訊 (IPC) 機制 而這意味著他們無法免受攻擊。這項提案增加 隔離功能 (將儲存裝置管理作業與其他共置驅動程式區隔) 但我們認為有彈性，即使在決策過程中 隔離邊界，若必須讓效能同時定位 軟體元件請參閱「設計」一節中的圖表。
隱私權注意事項
無可比較；
測試
現有的 fshost 測試套件是我們驗證的重要基礎 因為這些測試會模擬端對端流程來偵測 繫結至封鎖裝置
我們應該把握這個機會，開發更強大的區塊堆疊測試， 我們可用來確認兩者 導入方式相同
說明文件
儲存空間較低層的歷來記錄不足，因此 建議您運用整體架構改善這個做法 說明文件。對開發人員而言，儲存空間通常較不透明，但儲存空間本身 對系統開發人員和其他 Fuchsia 團隊 儲存空間：
缺點、替代方案和未知
缺點
我們無法將上述最低層的駕駛人放在同一個位置 而本次異動適用於最低等級的驅動程式 留在「駕駛架構」中儘管如此，我們並不認為這會造成問題 只移動了驅動程式中儲存空間堆疊的邊界 架構，而且界線不太可能涵蓋整個儲存體 (包括檔案系統) 之間)，所以在 部分儲存空間堆疊部分位於 DF 中
這項變更會降低實作 OOT 儲存體驅動程式的難度，但 沒有我們打算支援的功能；我們希望所有與儲存空間相關的 程式碼會在可預見的未來中留在樹狀結構內。
一開始，我們會以靜態方式編譯 Storage 主機，並提供所有可用的 格式，在舊版的驅動程式架構中，驅動程式是以動態方式載入 只包含該產品使用的如上所述 就會造成錯誤，之後如果再使用動態連結，我們就能解決問題
替代方案
最明顯的替代方法是不做此變更，也就是保留上層 驅動程式架構不過請注意，這不代表 沒有可做的工作我們還需要：
- 將上層區塊驅動程式遷移至 DFv2。
- 在以下位置設計用於探索及連接封鎖裝置的全新介面： 我們與 Driver Framework 團隊合作
- 將所有用戶端轉移至此新版介面，而非 dev-topological。
換句話說，在這兩種情況下，整合作業的廣度 範圍。本提案所需的額外工作是重新將 而非移植到 DFv2其他駕駛人 更複雜，我們得以在 Google 廣告代碼 ，因此需額外付費，而且還能享有多項好處 相同。
另一種做法是等待 Rust 型驅動程式推出 驅動程式架構，然後將現有驅動程式移植至 Rust，然後保留在測試中 驅動程式架構然而，時間表並沒有改變。 Devfs 的淘汰目標日期為 2024 年年底，我們目前並未承諾 Rust 驅動程式穩定支援時程，因此我們必須處理 Devfs 無論如何都會淘汰；我們也或許還能享有其他 Storage-host 政策。
既有藝術品和參考資料
無可比較；