本文件旨在說明 Fuchsia 檔案系統的概要觀點 對標準檔案系統作業的討論 (例如 開啟、讀取、寫入等)，以及實作使用者空間檔案系統的困境。 另外，本文件會介紹 VFS 層級逐步使用命名空間。 可用來與非儲存實體 (如 服務)。
檔案系統指的是服務
不同於常見的單體式核心，Fchsia 的檔案系統是完全存在的 使用者空間它們並未連結或載入核心；他們 只是使用者空間程序，能夠實作伺服器 檔案系統因此，可以變更 Fuchsia 的檔案系統。 修改過程不需要重新編譯核心，
圖 1：典型檔案系統程序區塊圖表。
如同 Fuchsia 上的其他原生伺服器， 檔案系統伺服器是使用原始控制介面 (而非系統) 來達成 呼叫。核心不具備檔案、目錄或檔案系統的相關資訊。阿斯 因此，檔案系統用戶端無法要求核心提供「檔案系統存取」
此架構意味著，與檔案系統的互動僅限於 以下介面：
- 透過檔案系統建立的通訊管道傳送的訊息 伺服器這些通訊管道可能是針對用戶端的當地通訊管道 檔案系統或遠端
- 初始化處理常式 (預計會大量設定於 每個檔案系統。網路檔案系統將需要網路存取權 永久檔案系統可能也需要封鎖裝置存取權、記憶體內檔案系統 只需要配置新的暫存頁面)。
透過這個介面，任何可透過管道存取的資源 的確是檔案系統的 檔案或目錄舉例來說，元件會放送 傳出目錄 ，其中包含 「功能」。
檔案生命週期
建立連線
為了開啟檔案，Fchsia 程式 (用戶端) 會將 RPC 要求傳送至檔案系統。 透過 FIDL 存取伺服器的資料
FIDL 會定義用於傳輸訊息及處理 檔案系統用戶端和伺服器而不是與核心實作 VFS 層，Fuchsia 會處理將要求傳送至檔案系統服務， 實作檔案、目錄和裝置的通訊協定。如要傳送 開放式要求，Fchsia 程序必須透過現有 寫入目錄；如要進一步瞭解這項程序，請參閱 開啟文件。
命名空間
在 Fuchsia 中，「命名空間」是存在的小型檔案系統 整個用戶端。就從基本的角度來看 將「/」儲存為根層級，並與該帳號代碼建立關聯，是相當基本做法 命名空間而不是常見的單數「全球」檔案系統命名空間, Fuchsia 可提供任意目錄處理常式來代表「根」、 限制命名空間的範圍為了限制這個範圍，Fuchsia 檔案系統刻意禁止透過 點號。
Fuchsia 程序可能會另外將特定路徑作業重新導向 檔案系統伺服器客戶提及「/bin」時，可選擇加入 將這些要求重新導向至代表「/bin」目錄的本機控制代碼。 而不要直接將要求傳送至「根目錄」的「bin」目錄 目錄。命名空間與所有檔案系統結構相同，不會顯示在 而是會在用戶端執行階段中實作 (例如 libfdio)，並在大部分的用戶端程式碼之間穿插 以及遠端檔案系統的控制代碼
由於命名空間是透過帳號代碼運作，且大部分的 Fuchsia 資源與服務 可透過帳號代碼存取，是非常強大的概念。 檔案系統物件 (例如目錄和檔案)、服務、裝置 套件和環境 (可透過特殊權限程序看到) 全都可以使用 ，且可在子項程序中任意組合。身為 命名空間讓您可以在命名空間中 應用程式。每個程序在「/svc」中觀察到的服務，則不一定 不符合其他程序看到的內容，因此可限製或重新導向 根據應用程式的啟動政策進行預測
進一步說明適用於限製程序的機制和政策 請參閱「 採用沙箱機制。
傳送資料
建立連線後，不論是檔案、目錄、裝置 後續作業也會透過 RPC 訊息傳輸。 這些訊息會透過一或多個控點傳送，並使用 伺服器會驗證並瞭解
如果是檔案、目錄、裝置和服務，這些作業會使用 FIDL 通訊協定。
舉例來說，若用戶端想搜尋檔案，就會傳送 Seek
並在 FIDL 訊息中標上所需位置和「whence」的訊息，
就會傳回新的跳轉位置如要截斷檔案，Truncate
訊息可能會與新的所需檔案系統一併傳送，而狀態訊息
。如要讀取目錄，請傳回 ReadDirents 訊息
，並傳回日數清單。如果這些要求傳送到
無法處理的檔案系統實體、發生錯誤，且
系統不會執行這項作業 (例如傳送至文字的 ReadDirents 訊息)
檔案)。
記憶體對應
對於可支援此功能的檔案系統，記憶體對應檔案會略高一些 變得複雜如要實際在檔案中建立「mmap」，用戶端會傳送「GetVmo」 並接收虛擬記憶體物件或 VMO 回應。這個物件 通常會使用虛擬記憶體 位址區域，或稱 VMAR。傳輸檔案內部的有限檢視畫面 「VMO」傳回用戶端需要進行額外作業 傳送層，以便他們知道自己傳回的是伺服器傳回的資料層 物件控制代碼。
藉由回傳這些虛擬記憶體物件，用戶端就能快速存取 不會實際產生 來回處理序間通訊 (IPC) 訊息。這項功能使 mmap 成為 企圖在檔案系統互動上產生高處理量的用戶端。
對路徑執行的其他作業
除了「開放式」作業外，還有另外幾個路徑導向 一些值得討論的操作：「rename」和「link」有別於「打開」 實際上是一次處理多個路徑，而不是只有 或 HTTP/HTTPS 位置這樣會使使用的流程變得複雜：如果呼叫 “rename(‘/foo/bar’, 「baz」)？」時，檔案系統必須設法：
- 即使兩條路線的起點不同 (例如 在本例中一個路徑從根開始，另一個路徑則從 CWD 開始)
- 開啟兩個路徑的父項目錄
- 同時操作父項目錄和結尾路徑名稱
為了滿足此行為，VFS 層利用 Zircon 概念 「Cookie」這些 Cookie 可讓用戶端作業儲存開啟項目 使用處理常式的狀態，並在稍後使用相同的 控制代碼Fuchsia 檔案系統透過這項功能 的一件事
這些多路徑作業執行以下操作：
- 開啟父項來源向量 (「/foo/bar」代表開啟「/foo」)
- 開啟目標父項 v 節點 (針對「baz」)，即代表開啟目前的
工作目錄)，並透過操作取得 Pod 符記
GetToken，這是檔案系統 Cookie 的控制代碼。 - 傳送「重新命名」要求至來源父項 V 節點，以及來源 和目的地路徑 (「bar」和「baz」)，以及取得的 此舉可讓檔案系統安全地參照 目的地節點 (間接) -- 如果用戶端提供的控制代碼無效， 核心會拒絕存取 Cookie 的要求，而伺服器會傳回 發生錯誤。
檔案系統生命週期
固定方式
Fshost 會負責在系統中掛接檔案系統。於 編寫、變更也仍在進行中，確保檔案系統以元件形式執行 ( fshost 仍會控制這些檔案系統的掛接。如果可能的話 將會使用靜態轉送請參閱 fuchsia.fs.startup/Startup 通訊協定。
檔案系統管理
對一系列檔案系統作業來說，這些作業視為相關的 「管理」，包括「卸載目前的檔案系統」。這些 作業是由 admin.fidl.檔案系統會匯出這項服務 以及檔案系統的根層級存取權
目前的檔案系統
鑑於 Fuchsia 架構採用模組化的特性， 新增檔案系統目前存在的檔案系統不多 打算滿足各種不同需求。
MemFS：記憶體內檔案系統
MemFS
的用途是對對 /tmp 等暫存檔案系統的要求導入要求，
完全存在於 RAM 中，且不會傳輸至基礎區塊裝置。
這個檔案系統目前也用於「啟動檔案系統」通訊協定
代表一組檔案和目錄的大型唯讀 VMO
開機時進入可供使用者存取的 Vnode 檔案 (這些檔案可在
/boot)。
MinFS：永久檔案系統
MinFS 是一種簡單的傳統檔案系統，能儲存 持續不間斷就像 MemFS 一樣，它會大量使用上述的 VFS 層 但與 MemFS 不同的是，這需要針對區塊裝置額外的帳號代碼 (會在啟動時傳輸至新的 MinFS 程序)。為了使用方便 MinFS 也提供各種工具，包括用於格式設定的「mkfs」、「fsck」 驗證的排序方式，以及「掛接」和「固定」的數值，用來計算增減 MinFS 將檔案系統轉換為命名空間
Blobfs：不可變更的完整性驗證套件儲存檔案系統
Blobfs 是一個簡易的平面檔案系統，針對「寫入一次，之後為唯讀」進行最佳化處理 資料，例如 套件。 除了兩項小型先決條件 (檔案名稱：確定性、內容) 檔案的 Merkle Tree 根可定址雜湊 (用於完整性驗證) 檔案大小相關知識 (藉由呼叫 「ftruncate」將 blob 寫入儲存空間)，Blobfs 看起來像 以及典型的檔案系統它可以掛接和卸載，看起來似乎含有 雜湊的單一平面目錄，而 blob 可透過作業存取 「開啟」、「閱讀」、「統計資料」和「mmap」。
FVM
Fuchsia Volume Manager 是「邏輯磁碟區管理員」可讓您在現有封鎖條件之外 裝置。現有功能包括新增、移除、擴充 縮減虛擬分區為了在內部透過 FVM 實現這些功能 會由實體與虛擬對應關係從 (虛擬分區、區塊) (切片、實體區塊)。為了將維護負擔降至最低 分別在稱為「配量」區塊的區塊中縮減/擴大切片是 原生區塊大小而中繼資料則將裝置的其餘部分分割為 切片。每個配量都是免費的，或各自屬於一個分區。 如果配量屬於分區，FVM 會保留相關中繼資料 使用 Slice，而其中片段的虛擬位址 該分區。
FVM 的磁碟配置如下所示，且已宣告 請按這裡。
+---------------------------------+ <- Physical block 0
| metadata |
| +-----------------------------+ |
| | metadata copy 1 | |
| | +------------------------+ | |
| | | superblock | | |
| | +------------------------+ | |
| | | partition table | | |
| | +------------------------+ | |
| | | slice allocation table | | |
| | +------------------------+ | |
| +-----------------------------+ | <- Size of metadata is described by
| | metadata copy 2 | | superblock
| +-----------------------------+ |
+---------------------------------+ <- Superblock describes start of
| | slices
| Slice 1 |
+---------------------------------+
| |
| Slice 2 |
+---------------------------------+
| |
| Slice 3 |
+---------------------------------+
| |
分區表是由數個虛擬分區組成
項目 (VPartitionEntry)。除了包含名稱和分區
識別碼，每個向量項目都含有已分配的
為這個大小指定配量
「配量分配表」是由已緊密封裝的切片項目組成。
(SliceEntry)。每個項目都包含
- 分配狀態
- 如果分配給節點
- 所屬的分區
- 分區中對應至什麼邏輯切片目標
您可以找到 FVM 程式庫 請按這裡。過程中 鋪面 部分分區會從主機複製到目標。也就是分區和 FVM 檔案本身可以在主機上建立如要這麼做，請使用主機端公用程式 請按這裡。 FVM 裝置/檔案的完整性可透過 fvm-check