JuiceFS 資料讀寫流程詳解

語言: CN / TW / HK

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