為了提升寫入效率，JuiceFS 提供了 writeback 功能。例如在寫入 1 萬條數據的案例中，啟用 writeback 后，數據傳輸在 10 秒 內完成；未啟用 writeback 時則需要 2 分鐘。然而，writeback 功能也伴隨著一些風險和使用限制。本文將詳細介紹 JuiceFS 的寫入機制，解析 writeback 的工作原理、適用場景以及使用時的注意事項，幫助用戶全面了解該功能的優勢與潛在問題。

01 JuiceFS 常規寫入模式

JuiceFS 數據寫入過程分為兩步：

• 數據塊寫入對象存儲并同步返回： 客戶端首先將切分好的數據塊寫入對象存儲。無論對象存儲的寫入速度如何（即使延遲高達數百毫秒），JuiceFS 都會等待其返回確認后再進行后續操作。
• 元數據寫入： 對象存儲返回響應后，JuiceFS 接著寫入元數據。

社區版和企業版在緩存失效機制上有所不同，因而其數據一致性的處理方式也不同。

• 社區版：每個客戶端都有內存中的元數據緩存，默認緩存失效時間為 1 秒。這是由于社區版缺乏主動通知機制，客戶端只能被動等待緩存過期才能獲取最新數據，所以我們折中將默認時間定在1秒，在確保只讀的場景下才建議調大該設置。
• 企業版：企業版支持主動通知緩存失效。當文件被修改后，企業版會向所有使用該文件的客戶端發送緩存失效通知，指示它們下次讀取時直接向元數據服務器請求數據，而不是使用本地緩存。這樣，企業版就可以實現更長的元數據緩存時間，進一步降低服務器壓力。

02 writeback 工作原理

writeback 模式主要目的是加速寫入過程。數據首先寫入本地磁盤，并且在 cache-dir 目錄下會額外創建一個 rawstaging 目錄，用于存放尚未上傳到對象存儲的本地數據，這部分數據稱為 staging 數據。

數據寫入本地磁盤并立即返回響應，寫入速度遠快于直接寫入對象存儲，通常在幾毫秒之間，高性能的 NVMe 磁盤延遲甚至可低至零點幾毫秒。寫入后，客戶端會通知元數據服務器數據已完成寫入，后續同步流程與常規寫入一致。然而，數據塊會異步上傳到對象存儲，上傳速度和完成時間取決于網絡和機器負載，因此在初期無法預知上傳的具體情況。

盡管 writeback 模式提供了更高的寫入速度，我們通常不推薦客戶使用此模式，主要是出于以下兩點考慮：

• 數據未上傳風險： 許多客戶在收到同步返回響應后，業務層面會誤認為數據已成功寫入到對象存儲。但實際上，數據可能仍停留在本地，尚未上傳。如果此時客戶關閉甚至銷毀機器，雖然重啟后數據會繼續上傳，但若機器被銷毀，數據將永久丟失。

• 其他節點無法馬上讀取： 寫到 staging 目錄下的本地文件在上傳對象存儲之前其他的節點是無法讀取的，所以這破壞了 read-after-write 的一致性，也破壞了 close-to-open 的強一致性，這在有些場合是不可接受的。

03 writeback 適用場景

盡管 writeback 模式存在一定風險，但它在提升寫入速度方面具有顯著優勢。特別是在需要快速響應的寫入場景中，如在寫入大量小文件時，只要能夠有效規避數據未及時寫入對象存儲以及異步上傳導致的數據丟失風險，writeback 模式 是一種高效且實用的選擇。用戶可根據實際需求靈活使用。

以一個向 JuiceFS 的 numbers 中寫入 1 萬條數據的案例為例。若不開啟緩存和寫緩存直接寫入數據，監控顯示對象存儲的 put 流量每次僅幾百字節，put 延遲為20多毫秒，寫入1萬行數據約需兩分鐘，速度極慢。

當開啟 writeback 模式后，put 延遲變化不大，但 put 流量實現了聚合，每次發送的數據量達到幾萬字節（如 21KB、70KB等）。此時，業務端 5 秒內即可收到返回，10 秒內就能完成數據傳輸，效率大幅提高。

在不同場景下，需要評估其風險點。寫入任務慢的風險在于耗時久，期間業務變動可能導致數據問題；而先快速寫完再聚合上傳，雖然存在數據丟失風險，但耗時短。在真實案例中，這種效率差異可能從 5 秒擴大到 5 小時，這 5 小時內業務變動帶來的風險不容忽視。

根據以上分析，我們總結了 writeback 模式的推薦場景：

1. 頻繁寫入檢查點的訓練任務：例如，某些訓練任務每小時寫入一次檢查點，寫入時 GPU 需等待返回才能繼續運行。開啟 writeback 模式 后，即使機器故障且無法恢復，損失僅為一小時的訓練數據，且故障概率較低。業務角度來看，寫入后立即返回可以顯著提高 GPU 利用率，減少等待時間。但如果一天只寫入一個檢查點，建議等待幾分鐘，確保數據寫入對象存儲后再返回，以保障數據安全。
2. 用戶開發環境：例如，在 AI 場景中，許多用戶將 home 目錄設置在 JuiceFS 中。若不開啟寫緩存，安裝一個軟件包可能需要三到五分鐘；而開啟 writeback 模式 后，安裝時間可縮短至十幾秒。由于這通常是個人目錄，也很少有共享其他掛載點訪問的情況存在，數據銷毀風險較低，因此可以考慮開啟 writeback 模式 來加速操作。
3. 小文件多或臨時解壓文件的場景：例如，從 JuiceFS 拉取文件并進行解壓時，涉及大量小文件的處理。開啟 writeback 模式 可以顯著提高解壓速度，提升效率。
4. 隨機寫入多的場景

關于 writeback 模式的應用，也可參考階躍星辰在大模型訓練場景中的實踐。他們采用分布式文件系統 GPFS 作為緩存盤，并將 staging 目錄也放在 GPFS 上，從而解決了數據安全性和數據不可讀的問題。需要注意的是，GPFS 的節點數量不能過多，否則可能帶來穩定性風險。盡管如此，收益非常顯著：在 Checkpoint 數據寫入過程中，啟用 writeback 模式大幅提升了寫入的容錯能力和吞吐性能。

04 未來優化方向

在 JuiceFS 企業版 5.3 版本中，我們計劃引入共享塊設備概念，以替代單節點本地磁盤的寫回模式。簡單而言，就是一個塊設備將被多個客戶端同時掛載來作為 staging 目錄，這樣就可以滿足 read-after-write 的一致性。而共享塊設備通常為云盤，具備高可靠性，不易出現故障，可以有效解決數據訪問一致性問題。

然而，共享云盤存在一定限制，一塊云盤最多支持 16 個客戶端掛載。為此，我們準備使用單掛載設備方案，即一臺機器掛載設備，其他機器通過該機器讀取數據，當有足夠多的節點提供足夠多的單掛載盤時，一定程度解決了數據熱點問題，是一個值得期待的在對象存儲之上的寫加速方案。