目前很多文件系統基于Fuse開發，作者深入鉆研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等），可能會導致后端服務器壓力增大。

有鑒于此，Fuse的作者在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

優化建議：一顆星