目前很多文件系統(tǒng)基于Fuse開發(fā)，作者深入鉆研Fuse代碼后，總結(jié)出開發(fā)此類文件系統(tǒng)時可考慮的優(yōu)化方案，拿出來與大家討論討論，如有不準確的地方，還望大家不吝賜教。閱讀本文前，我假設(shè)你對Fuse有了足夠多的了解（起碼知道Fuse有兩個模塊：Fuse Kernel 和LibFuse以及知道一個應(yīng)用程序調(diào)用行為如何傳遞至我們自己開發(fā)的基于Fuse的文件系統(tǒng)），否則，請先移步。

• 優(yōu)化1：延長元數(shù)據(jù)有效時間

Linux中每個打開文件在內(nèi)核中擁有兩種元數(shù)據(jù)信息：struct dentry和struct inode，它們是文件在內(nèi)核的基礎(chǔ)。所有對文件的操作，都需要先獲取文件這兩個結(jié)構(gòu)方可繼續(xù)下去，而這兩個結(jié)構(gòu)又是由具體文件系統(tǒng)負責構(gòu)造填充。以下兩點解釋了元數(shù)據(jù)優(yōu)化的必要性：

1).  應(yīng)用程序調(diào)用文件系統(tǒng)操作系統(tǒng)接口時，傳入的參數(shù)一般為文件路徑，如open(“a/b/c/d.txt”)，內(nèi)核需要對路徑名進行解析，從根目錄開始，根據(jù)路徑中的每個分量獲取其dentry和inode，接著解析路徑的下一個分量，直至解析出目的文件的inode和dentry，如果路徑名分量中的dentry沒有緩存在內(nèi)存中，需要從具體文件系統(tǒng)上讀出（這就耗時多了）。

2). 很多應(yīng)用程序喜歡調(diào)用stat接口以獲取文件屬性，內(nèi)核實現(xiàn)其實是找到文件inode，從inode中獲取文件屬性。如果inode沒有被緩存，則需要從具體文件系統(tǒng)中獲?。赡軙芎臅r）。

因為Fuse的內(nèi)核模塊只是一個橋梁，連接了應(yīng)用程序和我們基于Fuse開發(fā)的文件系統(tǒng)。所以，按照道理說，每次獲取文件/目錄的inode以及dentry的時候Fuse內(nèi)核模塊都應(yīng)該去LibFuse以及我們的文件系統(tǒng)走一遭。

但是這樣做的話缺點非常明顯：IO路徑拉長，效率變低，而且假如我們基于fuse開發(fā)的文件系統(tǒng)是網(wǎng)絡(luò)文件系統(tǒng)（例如NOS等），可能會導(dǎo)致后端服務(wù)器壓力增大。

有鑒于此，F(xiàn)use的作者在Kernel Fuse模塊中增加了元數(shù)據(jù)緩存，包含dentry和inode緩存。相比本地文件系統(tǒng)，我們必須時刻警惕一個問題：緩存有效性。所以，如何在提升性能的同時又盡量保證正確性是一個棘手的問題。

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

優(yōu)化方法：fuse掛載指定 –o entry_timeout=T –o attr_timeout=T

優(yōu)化建議：五顆星

• 優(yōu)化2：擴大每次寫入頁面數(shù)

應(yīng)用程序每次對基于Fuse開發(fā)的文件系統(tǒng)的文件寫入必先經(jīng)過Kernel Fuse模塊，Kernel Fuse其實是有很大權(quán)限決定何時將數(shù)據(jù)寫入到用戶態(tài)文件系統(tǒng)的。寫的越頻繁，效率必然越低，但一致性可能會更好，控制寫入頻率其實也是一個權(quán)衡的過程。

如果稍微熟悉Kernel你可能就會知道內(nèi)核的IO其實是以Page為單位的。內(nèi)核會將應(yīng)用程序的寫入請求按照PAGE_SIZE劃分成多個page，然后再對page進行IO，簡潔優(yōu)美。

如果不作優(yōu)化，Kernel Fuse對應(yīng)用程序的每次page都會調(diào)用一次用戶態(tài)文件系統(tǒng)的寫操作，這樣假如我們用戶態(tài)的64KB的寫請求，按照默認的PAGE_SIZE(4KB)可能會觸發(fā)16次的用戶態(tài)寫，實際IO次數(shù)被放大，效率嚴重下降。如果采取優(yōu)化，Kernel Fuse默認會每128KB才觸發(fā)一次用戶態(tài)文件系統(tǒng)寫調(diào)用，當然亦可指定觸發(fā)寫調(diào)用的閾值。

優(yōu)化方法：fuse掛載指定 –o big_write –o max_write=N

優(yōu)化建議：五顆星

• 優(yōu)化3：開啟內(nèi)核讀緩存

Linux文件系統(tǒng)實現(xiàn)充分利用了內(nèi)存來緩存文件數(shù)據(jù)，這樣應(yīng)用程序很多時候讀文件其實只需從內(nèi)核緩沖區(qū)拷貝數(shù)據(jù)至用戶態(tài)緩沖區(qū)即可，根本不必啟動磁盤IO。

由于Fuse的特殊性，需要嚴格控制數(shù)據(jù)緩存行為（看看我們前面提到的元數(shù)據(jù)緩存吧），因為可能我們實現(xiàn)的基于Fuse的文件系統(tǒng)其實是一個網(wǎng)絡(luò)文件系統(tǒng)，那么如果使用內(nèi)核緩存，可能就讀到臟數(shù)據(jù)，因為作為用戶態(tài)的你是很難控制內(nèi)核的行為的。

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

優(yōu)化方法：fuse掛載指定 –o kernel_cache –o auto_cache

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

優(yōu)化建議：三顆星

• 優(yōu)化4：擴大預(yù)讀窗口

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

Fuse允許掛載用戶態(tài)文件系統(tǒng)時指定預(yù)讀窗口大小，F(xiàn)use會用該設(shè)定值作為***的預(yù)讀窗口大小，若不指定，會采用Linux默認的***預(yù)讀窗口大小128KB。但是其實如果你設(shè)置了Fuse的預(yù)讀窗口超過Linux默認的128KB也是徒勞，因為VFS不允許預(yù)讀窗口超過128KB限制，所以總的來說，優(yōu)化的意義不大。

優(yōu)化方法：fuse掛載指定 –o max_readahead = N

優(yōu)化建議：一顆星

• 優(yōu)化5：使用DirectIO取代BufferIO

有些時候，應(yīng)用程序希望繞過OS的緩存而自己管理緩存（如數(shù)據(jù)庫），這需要文件系統(tǒng)實現(xiàn)DIRECTIO方法。

同樣，貼心的Fuse作者也為我們提供了directIO方式的讀寫。相比BufferIO方式，DirectIO的***優(yōu)勢在于減少了數(shù)據(jù)從應(yīng)用程序緩沖區(qū)拷貝至內(nèi)核態(tài)的開銷，對于大量順序?qū)懙膽?yīng)用場景，性能可能會有一定提升。

當然，如果采用DirectIO，恐怕***的問題就是read也無法使用內(nèi)核緩存了，很多時候這是我們無法忍受的，常常來說，文件系統(tǒng)讀請求會遠多于寫，所以，優(yōu)化前望三思。

優(yōu)化方法：fuse掛載指定 -o direct_io

優(yōu)化建議：一顆星