對於檔案系統而言，其讀寫的效率對整體的系統效能有決定性的影響，本文我們將通過介紹 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✿)