對於文件系統而言，其讀寫的效率對整體的系統性能有決定性的影響，本文我們將通過介紹 JuiceFS 的讀寫請求處理流程，讓大家對 JuiceFS 的特性有更進一步的了解。
寫入流程
JuiceFS 對大文件會做多級拆分（參見 JuiceFS 如何存儲文件），以提高讀寫效率。在處理寫請求時，JuiceFS 先將數據寫入 Client 的內存緩沖區，並在其中按 Chunk/Slice 的形式進行管理。Chunk 是根據文件內 offset 按 64 MiB 大小拆分的連續邏輯單元，不同 Chunk 之間完全隔離。每個 Chunk 內會根據應用寫請求的實際情況進一步拆分成 Slices；當新的寫請求與已有的 Slice 連續或有重疊時，會直接在該 Slice 上進行更新，否則就創建新的 Slice。
Slice 是啟動數據持久化的邏輯單元，其在 flush 時會先將數據按照默認 4 MiB 大小拆分成一個或多個連續的 Blocks，並上傳到對象存儲，每個 Block 對應一個 Object；然后再更新一次元數據，寫入新的 Slice 信息。顯然，在應用順序寫情況下，只需要一個不停增長的 Slice，最后僅 flush 一次即可；此時能最大化發揮出對象存儲的寫入性能。
以一次簡單的 JuiceFS 基准測試為例，其第一階段是使用 1 MiB IO 順序寫 1 GiB 文件，數據在各個組件中的形式如下圖所示：
注意：圖中的壓縮和加密默認未開啟。欲啟用相關功能需要在 format 文件系統的時候添加
--compress value或--encrypt-rsa-key value選項。
這里再放一張測試過程中用 stats 命令記錄的指標圖，可以更直觀地看到相關信息：
上圖中第 1 階段：
- 對象存儲寫入的平均 IO 大小為
object.put / object.put_c = 4 MiB，等於 Block 的默認大小 - 元數據事務數與對象存儲寫入數比例大概為
meta.txn : object.put_c ~= 1 : 16，對應 Slice flush 需要的 1 次元數據修改和 16 次對象存儲上傳，同時也說明了每次 flush 寫入的數據量為 4 MiB * 16 = 64 MiB，即 Chunk 的默認大小 - FUSE 層的平均請求大小為約
fuse.write / fuse.ops ~= 128 KiB，與其默認的請求大小限制一致
相較於順序寫來說，大文件內隨機寫的情況要復雜許多；每個 Chunk 內可能存在多個不連續的 Slice，使得一方面數據對象難以達到 4 MiB 大小，另一方面元數據需要多次更新。同時，當一個 Chunk 內已寫入的 Slices 過多時，會觸發 Compaction 來嘗試合並與清理這些 Slices，這又會進一步增大系統的負擔。因此，JuiceFS 在此類場景下會比順序寫有較明顯的性能下降。
小文件的寫入通常是在文件關閉時被上傳到對象存儲，對應 IO 大小一般就是文件大小。從上面指標圖的第 3 階段（創建 128 KiB 小文件）中也可以看到：
- 對象存儲 PUT 的大小就是 128 KiB
- 元數據事務數大致是 PUT 計數的兩倍，對應每個文件的一次 Create 和一次 Write
值得一提的是，對於這種不足一個 Block 的對象，JuiceFS 在上傳的同時還會嘗試寫入到本地 Cache（由 --cache-dir 指定，可以是內存或硬盤），以期能提升后續可能的讀請求速度。從指標圖中也可以看到，創建小文件時 blockcache 下有同等的寫入帶寬，而在讀取時（第 4 階段）大部分均在 Cache 命中，這使得小文件的讀取速度看起來特別快。
由於寫請求寫入 Client 內存緩沖區即可返回，因此通常來說 JuiceFS 的 Write 時延非常低（幾十微秒級別），真正上傳到對象存儲的動作由內部自動觸發（單個 Slice 過大，Slice 數量過多，緩沖時間過長等）或應用主動觸發（關閉文件、調用 fsync 等）。緩沖區中的數據只有在被持久化后才能釋放，因此當寫入並發比較大或者對象存儲性能不足時，有可能占滿緩沖區而導致寫阻塞。
具體而言，緩沖區的大小由掛載參數 --buffer-size 指定，默認為 300 MiB；其實時值可以在指標圖的 usage.buf 一列中看到。當使用量超過閾值時，JuiceFS Client 會主動為 Write 添加約 10ms 等待時間以減緩寫入速度；若已用量超過閾值兩倍，則會導致新的寫入暫停直至緩沖區得到釋放。因此，在觀察到 Write 時延上升以及 Buffer 長時間超過閾值時，通常需要嘗試設置更大的 --buffer-size。另外，通過增大 --max-uploads 參數（上傳到對象存儲的最大並發數，默認為 20）也有可能提升寫入到對象存儲的帶寬，從而加快緩沖區的釋放。
回寫（Writeback）模式
當對數據的一致性和可靠性要求並不高時，還可以在掛載時添加 --writeback 以進一步提升系統性能。回寫模式開啟后，Slice flush 僅需寫到本地 Staging 目錄（與 Cache 共享）即可返回，數據由后台線程異步上傳到對象存儲。請注意，JuiceFS 的回寫模式與通常理解的先寫內存不同，是需要將數據寫入本地 Cache 目錄的（具體的行為根據 Cache 目錄所在硬件和本地文件系統而定）。換個角度理解，此時本地目錄就是對象存儲的緩存層。
回寫模式開啟后，還會默認跳過對上傳對象的大小檢查，激進地盡量將所有數據都保留在 Cache 目錄。這在一些會產生大量中間文件的場景（如軟件編譯等）特別有用。
此外，JuiceFS v0.17 版本還新增了 --upload-delay 參數，用來延緩數據上傳到對象存儲的時間，以更激進地方式將其緩存在本地。如果在等待的時間內數據被應用刪除，則無需再上傳到對象存儲，既提升了性能也節省了成本。同時相較於本地硬盤而言，JuiceFS 提供了后端保障，在 Cache 目錄容量不足時依然會自動將數據上傳，確保在應用側不會因此而感知到錯誤。這個功能在應對 Spark shuffle 等有臨時存儲需求的場景時非常有效。
讀取流程
JuiceFS 在處理讀請求時，一般會按照 4 MiB Block 對齊的方式去對象存儲讀取，實現一定的預讀功能。同時，讀取到的數據會寫入本地 Cache 目錄，以備后用（如指標圖中的第 2 階段，blockcache 有很高的寫入帶寬）。顯然，在順序讀時，這些提前獲取的數據都會被后續的請求訪問到，Cache 命中率非常高，因此也能充分發揮出對象存儲的讀取性能。此時數據在各個組件中的流動如下圖所示：
注意：讀取的對象到達 JuiceFS Client 后會先解密再解壓縮，與寫入時相反。當然，如果未啟用相關功能則對應流程會直接跳過。
做大文件內隨機小 IO 讀取時，JuiceFS 的這種策略則效率不高，反而會因為讀放大和本地 Cache 的頻繁寫入與驅逐使得系統資源的實際利用率降低。不幸的是，此類場景下一般的緩存策略很難有足夠高的收益。此時可考慮的一個方向是盡可能提升緩存的整體容量，以期達到能幾乎完全緩存所需數據的效果；另一個方向則可以直接將緩存關閉（設置 --cache-size 0），並盡可能提高對象存儲的讀取性能。
小文件的讀取則比較簡單，通常就是在一次請求里讀取完整個文件。由於小文件寫入時會直接被緩存起來，因此類似 JuiceFS bench 這種寫入后不久就讀取的訪問模式基本都會在本地 Cache 目錄命中，性能非常可觀。
總結
以上就是本文所要簡單闡述的 JuiceFS 讀寫請求處理流程相關的內容，由於大文件和小文件的特性差異，JuiceFS 通過對不同大小的文件執行不同的讀寫策略，從而大大的提升了整體性能和可用性，可以更好的滿足用戶對不同場景的需求。
推薦閱讀：如何在 Kubernetes 集群中玩轉 Fluid + JuiceFS
如有幫助的話歡迎關注我們項目 Juicedata/JuiceFS 喲！ (0ᴗ0✿)