一、背景和問題

1. EXT4日志的問題

隨著計算機系統(tǒng)加載數(shù)百個CPU內核，文件系統(tǒng)的可擴展性得到進一步強調。因此本文主要定位服務器中廣泛使用的Ext4文件系統(tǒng)在做日志記錄時的可擴展性問題。EXT4日志有兩個嚴重的缺點；串行提交并提交原始頁面緩存條目。

串行提交：在EXT4中，日志提交是嚴格的串行活動。只有在前面的日志提交完成后，它才能提交后面的日志事務。因此，在EXT4中，一次最多只能有一個正在運行的事務，最多只能有一個提交事務。圖1展示了串行提交的一個示例：

將前面的fsync()和后面的fsync()的日志事務分別標記為Tx1和Tx2。JBD線程僅在完成提交Tx1后才開始提交Tx2（t3時刻）。

提交原始頁面緩存條目：EXT4使用原始頁面緩存條目將更新的內容提交給磁盤。它不會為日志提交創(chuàng)建更新的副本。如果關聯(lián)的頁面緩存條目被提交到磁盤，則需要更新文件系統(tǒng)狀態(tài)的應用程序將被阻塞。這種情況也叫做事務沖突，會嚴重影響EXT4的日志記錄可擴展性。

2. EXT4日志可擴展性問題的詳細分析

本文通過EXT4執(zhí)行串行日志提交和BarrierFS執(zhí)行并發(fā)日志操作來探索文件系統(tǒng)日志中的可伸縮性平靜，最終確認了影響EXT4 和 BarrierFS 性能可擴展性的四個主要組件；事務沖突、串行刷新、事務鎖定間隔的長度和復合日志的合并程度。

(1) 事務沖突

事務沖突技術值定義為試圖修改DMA下的日志塊的文件操作數(shù)量。盡管 EXT4 的影子分頁功能可以解決事務沖突，但 EXT4 日志記錄仍然存在大量事務沖突。

即使BarrierFS同時提交多個事務，它也會使用單獨的刷新命令刷新每個事務。由于每個日志提交都會在存儲設備上產(chǎn)生單獨的刷新，因此BarrierFS 的并發(fā)日志設計的好處是體現(xiàn)不出來的。此外，當正在運行的事務試圖在flush下修改日志塊時，它們都會發(fā)生沖突并被阻塞。這種提交事務的更高并發(fā)性導致幾乎 100% 的文件操作在所有線程中都遭受事務沖突。

(2) 事務鎖定

并發(fā)日志中可伸縮性失敗的主要原因之一是延長的鎖定間隔。

對EXT4,事務鎖定間隔的長度可以忽略不計，因為鎖定期只是等待未完成的文件操作完成的時間，一般來說是很短的。

BarrierFS可以在正在運行的事務擺脫沖突之前過早地將其置于鎖定狀態(tài)，直到所有未完成的文件操作完成并且所有沖突都得到解決。因此，一個正在運行的事務在 BarrierFS 中停留在鎖定狀態(tài)的時間間隔比在 EXT4 中長得多。

兩個文件系統(tǒng)鎖定時間的對比如圖2：

(3) 有限合作

影響文件系統(tǒng)日志性能可伸縮性的關鍵因素是日志事務的合并程度——日志事務中文件系統(tǒng)操作的數(shù)量。

EXT4 日志的嚴格串行性質實際上有助于增加復合日志的合并程度。當日志提交正在進行時，所有與傳入文件操作相關的更新都被插入到正在運行的事務中。因此，隨著線程數(shù)量的增加，合并機會會增加。

而對于BarrierFS，由于它過早地將正在運行的事務置于鎖定狀態(tài)，從而減少了將多個文件操作合并到單個日志事務中的機會。

二、設計

作者通過以下幾個技術點實現(xiàn)了一個支持高并發(fā)的日志文件系統(tǒng)—CJFS。

1. 雙線程日志

作者將日志提交過程分為兩個階段，即提交階段和刷新階段，并為每個階段分配單獨的線程，即提交線程和刷新線程。提交線程負責向存儲發(fā)出日志事務的寫請求。完成后，存儲設備會向主機發(fā)送中斷，通知請求服務已完成。刷新線程負責使日志塊和提交塊持久化。一旦中斷到來，刷新線程被喚醒，并向存儲發(fā)出刷新命令，使日志塊和提交塊持久化。

如圖3所示，通過分離提交線程和刷新線程，CJFS 可以在不等待前面的日志()提交完成的情況下提交后續(xù)事務。

2. 多版本影子頁

為了解決事務沖突，作者提出了多版本影子分頁。當提交線程啟動日志提交時，它會創(chuàng)建日志事務中所有頁面的影子副本。在提交日志事務時，提交線程使用事務中每一頁的影子副本來將日志事務傳輸?shù)酱鎯υO備，而不是使用原始頁面。由于日志模塊使用影子頁面進行日志提交，后續(xù)的文件操作可以更新原始頁面。

3. 機會性合并

由于影子頁面的數(shù)量有限，如果所有預分配的影子頁面都用于保存日志，仍然會發(fā)生事務沖突。如果發(fā)生事務沖突，正在運行的事務將進入鎖定狀態(tài)，并且所有修改文件系統(tǒng)狀態(tài)的后續(xù)文件操作都將被阻止。為了解決這個問題，作者提出了機會合并。當所有未完成的文件操作完成時，提交線程檢查是否存在任何沖突。如果存在沖突，提交線程會將鎖定狀態(tài)的事務返回到運行狀態(tài)并被阻塞。當提交線程被阻塞后，正在運行的事務可以繼續(xù)容納新傳入的日志塊。

如圖四展示了機會合并的一個例子，在兩個 LOCKED 狀態(tài)之間的時間段內處于RUNNING狀態(tài)。在運行事務的狀態(tài)變?yōu)镽UNNING狀態(tài)后，所有被阻塞等待日志句柄的掛起文件操作都被發(fā)布日志句柄。借助這樣的機會合并，CJFS 可以將大量文件操作合并到正在運行的事務中，從而提高文件系統(tǒng)操作的并發(fā)性。

4. 復合刷新

為了使 CJFS 的日志以完全并發(fā)的方式工作，提交線程和刷新線程都應該能夠以并發(fā)的方式處理關聯(lián)的任務。針對EXT4和BarrierFS的序列化刷新問題，作者提出了一種復合刷新的概念：當刷新線程即將發(fā)送刷新命令時，它會檢查是否存在任何后續(xù)提交事務，如果后續(xù)提交事務不存在，則發(fā)送刷新命令；如果存在接下來的提交事務，它會改為發(fā)送cache barrier命令（控制閃存設備保證請求處理順序的命令），從而將持久化事務的任務委托給后面的事務提交請求。通過cache barrier命令，存儲控制器可以確保各個事務的日志塊按順序持久化。

圖5說明了復合刷新的工作原理。當flush線程傳輸完事務后，flush線程開始傳輸事務，而不是調用flush來刷新事務。當刷新線程完成傳輸事務時，它發(fā)現(xiàn)沒有其他正在提交的事務正在運行。然后，它調用flush使事務和事務持久化。

三、實驗效果

1. 實驗設置

作者將CJFS與BarrierFS、SpanFS [15]、Vanilla EXT4 和帶有 Fast-Commit的EXT4進行了比較。同時使用三個基準測試集進行測試：用于郵件服務器的varmail，用于文件服務器的dbench，以及MySQL上的 OLTP-Insert。測試平臺為40核服務器（兩個Intel Xeon Gold 6230處理器和512 GB DRAM）和三星970 Pro SSD（MLC閃存，NVMe）進行實驗。

2. 實驗結果

圖6

可以看到在多種測試集及其對應的多種數(shù)據(jù)更新場景下，CJFS都能達到最好的多核性能擴展效果。