目前很多文件系統基於Fuse（ fuse.sourceforge.net/ ）開發，在較為深入鑽研Fuse實現後，總結出開發此類文件系統時可考慮的優化方案，拿出來與大家討論討論，如有不準確的地方，還望大家不吝賜教。閱讀本文前，我假設你對Fuse有了足夠多的了解（起碼知道Fuse有兩個模塊：Fuse Kernel 和LibFuse以及知道一個應用程序調用行為如何傳遞至我們自己開發的基於Fuse的文件系統），否則，請先移步。

優化1：延長元數據有效時間

Linux中每個打開文件在內核中擁有兩種元數據信息：struct dentry和struct inode，它們是文件在內核的基礎結構。所有對文件的操作，都需要先獲取文件這兩個結構方可繼續下去，而這兩個結構又是由具體文件系統負責構造填充。以下兩點解釋了元數據優化的必要性：

  1. 應用程序調用文件系統操作系統介面時，傳入的參數一般為文件路徑，如open（「a/b/c/d.txt」），內核需要對路徑名進行解析，從根目錄開始，根據路徑中的每個分量獲取其dentry和inode，接著 加粗文字 解析路徑的下一個分量，直至解析出目的文件的inode和dentry，如果路徑名分量中的dentry沒有緩存在內存中，需要從具體文件系統上讀出（這就耗時多了）。
  2. 很多應用程序喜歡調用stat介面以獲取文件屬性，內核實現其實是找到文件inode，從inode中獲取文件屬性。如果inode沒有被緩存，則需要從具體文件系統中獲取（可能會很耗時）。

因為Fuse的內核模塊只是一個橋樑，連接了應用程序和我們基於Fuse開發的文件系統。所以，按照道理說，每次獲取文件/目錄的inode以及dentry的時候Fuse內核模塊都應該去LibFuse以及我們的文件系統走一遭。

但是這樣做的話缺點非常明顯：IO路徑拉長，效率變低，而且假如我們基於fuse開發的文件系統是網路文件系統（例如NOS等），可能會導致後端伺服器壓力增大。

有鑒於此，Kernel Fuse模塊中增加了元數據緩存，包含dentry和inode。相比本地文件系統，我們必須時刻警惕一個問題：緩存有效性。所以，如何在提升性能的同時又盡量保證正確性是一個棘手的問題。

利用fuse掛載我們自己文件系統時，可指定dentry以及inode屬性有效時間，當然這個有效時間得具體問題具體設置了，無統一答案。

優化方法：fuse掛載指定 –o entry_timeout=T –o attr_timeout=T

優化建議：五顆星

優化2：擴大每次寫入頁面數

應用程序每次對基於Fuse開發的文件系統的文件寫入必先經過Kernel Fuse模塊，Kernel Fuse其實是有很大許可權決定何時將數據寫入到用戶態文件系統的。寫的越頻繁，效率必然越低，但一致性可能會更好，控制寫入頻率其實也是一個權衡的過程。

稍微熟悉Kernel你可能就會知道內核的IO其實是以Page為單位的。內核會將應用程序的寫入請求按照PAGE_SIZE劃分成多個page，然後再對page進行IO，簡潔優美。

如果不作優化，Kernel Fuse對應用程序的每次page都會調用一次用戶態文件系統的寫操作，這樣假如我們用戶態的64KB的寫請求，按照默認的PAGE_SIZE（4KB）可能會觸發16次的用戶態寫，實際IO次數被放大，效率嚴重下降。優化後Kernel Fuse默認會每128KB才觸發一次用戶態文件系統寫調用，當然亦可指定觸發寫調用的閾值。

優化方法：fuse掛載指定 –o big_write –o max_write=N

優化建議：五顆星

優化3：開啟內核讀緩存

Linux文件系統實現充分利用了內存來緩存文件數據，這樣應用程序很多時候讀文件其實只需從內核緩衝區拷貝數據至用戶態緩衝區即可，根本不必啟動磁碟IO。

由於Fuse的特殊性，需要嚴格控制數據緩存行為（看看我們前面提到的元數據緩存吧），因為可能我們實現的基於Fuse的文件系統其實是一個網路文件系統，那麼如果使用內核緩存，可能就讀到臟數據，因為作為用戶態的你是很難控制內核的行為的。

不過Fuse的作者非常周到，它提供了多種掛載選項，來控制緩存行為，但友情提醒：一旦選擇開啟緩存，請為自己的可能讀的過期數據負責。

優化方法：fuse掛載指定 –o kernel_cache –o auto_cache

順便提一句：我們上面說的都是參數kernel_cache的行為，沒有說明auto_cache的行為，留給各位讀者仔細研究吧，提個醒：該選項是基於文件修改時間進行內核緩存有效性檢測的優化策略。

優化建議：三顆星

優化4：擴大預讀窗口

預讀是在是一件有趣的事情。Linux內核通過預讀改變了應用程序的原始讀行為。比如應用程序發起了一個16KB的讀請求，內核可能莫名其妙地讀取64KB數據等。當然，它這麼做肯定有其道理，簡單來說：一切為了性能，為了性能的一切。另外，我會在近期推出一篇預讀相關文章，詳細闡述預讀機制，敬請關注。

Fuse允許掛載用戶態文件系統時指定預讀窗口大小，Fuse會用該設定值作為最大的預讀窗口大小，若不指定，會採用Linux默認的最大預讀窗口大小128KB。但是其實如果你設置了Fuse的預讀窗口超過Linux默認的128KB也是徒勞，因為VFS不允許預讀窗口超過128KB限制，所以總的來說，優化的意義不大。

優化方法：fuse掛載指定 –o max_readahead = N

優化建議：一顆星

優化5：使用DirectIO取代BufferIO

某些時候，應用程序希望繞過OS的緩存而自己管理緩存（如資料庫），這需要文件系統實現DIRECTIO方法。

同樣，Fuse也貼心地為我們提供了directIO方式的讀寫。相比BufferIO方式，DirectIO的最大優勢在於減少了數據從應用程序緩衝區拷貝至內核態的開銷，對於大量順序寫的應用場景，性能可能會有一定提升。

當然，如果採用DirectIO，恐怕最大的問題就是read也無法使用內核緩存了，很多時候這是我們無法忍受的，常常來說，文件系統讀請求會遠多於寫，所以，優化前望三思。

優化方法：fuse掛載指定 -o direct_io

優化建議：一顆星


推薦閱讀：
相关文章