很多的用戶在提到 Ceph 性能的時候都會提到“寫放大”這點，實際上就是 FileJournal 在起作用。只要使用默認的 FileStore，所有數據包括 metadata 都會在 FileJournal 上預寫一份。那么本文就會介紹 FileJournal 在 FileStore 存儲引擎上提供的作用。
作用
FileJournal 就是數據庫中常見的 WAL(Write Ahead Log) 實現，主要提供了事務的一致性和原子性。Ceph 數據訪問所提供的寫操作在落到 ObjectStore 時實際上會產生多個寫操作，為了保證用戶層面的寫操作的原子性，避免 FileStore 在執行多個操作時發生意外造成中間狀態而無法追溯或者回滾，我們需要引入 Journal 來作為日志。使得 OSD 進程在非正常退出后再啟動可以從 Journal 中恢復之前正在執行的操作。
除此之外，FileJournal 提供了更短的寫操作耗時，因為用戶 IO 操作到達 FileStore 以后，只要經過 FileJournal 存儲后都可以立即回復給用戶，無需等待操作正常落盤。對於大量隨機小寫來說，這實際上能大大提高單個 OSD 的處理能力。
工作流程
如上圖所示，所有 PG 層提交事務都會在 FileStore 經過一層 Throttle 直接進入 FileJournal 隊列。然后有后面的不同類型線程都是單一線程，以 Pipeline 的形式最大化 FileJournal 的吞吐量。IO 從 Journal Queue 被提取后由 Write Thread 進行處理，圖上只標出了 AIO，實際上如果 OS 不支持 AIO+DIO 的方式，那么就會采用 write+flush 的組合。在這里，Write Thread 會盡可能獲取多的隊列事務進行批量提交，每個事務都會以頁對齊的方式補零后者重新編排，最后提交 IO。Write Finish Thread 實際上只在 AIO+DIO 中存在，主要是為了收割正在進行的 IO，收購后提交給 Finisher Thread。
可能的改進
日志的實現實際上並不是一個簡單的話題，它的邏輯非常簡單但在 IO 程序中起到非常重要的作用，也是用戶寫操作最重要的延時消耗者。因此如何最大化日志來提高 IO 吞吐量和延遲的討論早存在於學術和工業屆。Pipeline、減小臨界區和批量提交是主要的手段，FileJournal 采用多個線程協同的方式而不是多個獨立工作線程單獨工作的形式，兩者各有優劣。目前 FileJournal 在設計上沒有太大的問題，在實現上需要更加 SMART，解決不同大小 IO size 的相互影響。除此之外，非常大或者對象存儲的工作場景下，跳過 FileJournal 直接落盤是用戶期待的方式，但是目前 FileJournal 與 FileStore 耦合嚴重，因此社區會重起一個新的 Backend 來解決這些問題。