Linux用來支援使用者空間檔案系統的核心模組名叫FUSE。 fuse全名為“Filesystem in Userspace”，中文意思是“用戶空間檔案系統”，指完全在用戶態實現的檔案系統，是Linux中用於掛載某些網路空間，是一個通用作業系統重要的組成部分。
本教學操作環境：linux7.3系統、Dell G3電腦。
linux fuse是什麼
使用者空間檔案系統（Filesystem in Userspace），指完全在使用者態實作的檔案系統，是Linux中用於掛載某些網路空間，如SSH，到本地檔案系統的模組，在SourceForge上可以找到相關內容。
Linux用來支援使用者空間檔案系統的核心模組叫做FUSE，FUSE一詞有時特別指Linux下的使用者空間檔案系統。是一個通用作業系統重要的組成部分。傳統上作業系統在核心層面上對檔案系統提供支援。而通常內核態的程式碼難以調試，生產率較低。
所謂“用戶態檔案系統”，是指一個檔案系統的data和metadata都是由使用者狀態的程序提供的（這種程序稱為"daemon"）。對於micro-kernel的作業系統來說，在使用者態實作檔案系統不算什麼，但對於macro-kernel的Linux來說，意義就有所不同。
雖然叫做用戶態檔案系統，但不代表其完全不需要核心的參與，因為在Linux中，對檔案的存取都是統一透過VFS層提供的核心介面進行的（例如open/read），因此當一個進程（稱為"user"）存取由daemon實現的檔案系統時，依然需要途徑VFS。
當VFS接到user程序對檔案的存取請求，並且判斷出該檔案是屬於某個用戶態檔案系統（根據mount type），就會將這個請求轉交給一個名為"fuse"的內核模組。而後，"fuse"將該請求轉換為和daemon之間約定的協定格式，傳送給daemon程序。
可見，在這個三方關係中，"fuse"這個核心模組起的是一個轉接的作用，它幫助建立了VFS（也可以說是user進程）和daemon之間的交流通道，通俗點說，它的角色其實就是一個「代理」。
這一整套框架的實作在Linux中即為FUSE (Filesystem in Userspace)。如圖1所示，紅框的部分才是FUSE類型檔案系統的具體實現，才是使用者態檔案系統的設計者可以發揮的空間。目前，已有不下百種基於FUSE實作的檔案系統（一些基於核心的檔案系統也可以porting成用戶態檔案系統，例如ZFS和NTFS），而本文將選用一個現成的fuse-sshfs來進行示範。
首先安裝fuse-sshfs的軟體包，使用以下的指令進行檔案系統的mount（將遠端機器的"remote-dir"目錄掛載到本機的"local-dir"目錄）：
sshfs##之後，在"/sys/fs"目錄下，將產生一個名為"fuse"的資料夾，同時可以看到"fuse"核心模組已載入（其對應的裝置為"/dev/fuse"），且本機的掛載目錄的類型已被載入（其對應的裝置為"/dev/fuse"），且本機的掛載目錄的類型已成為" fuse.sshfs"：:
#【第一輪】
最開始是permission的校驗，不過這裡的校驗並不等同於VFS的權限校驗，它的主要目的是為了避免其他user存取到了自己私有的fuse檔案系統。
然後就是根據檔案路徑尋找檔案的inode。由於是新建的文件，inode並不在核心的inode cache中，所以需要向daemon發送"lookup"的請求：
這些請求會被放入一個pending queue中，等待daemon進程的回复，而user進程將陷入睡眠：
作為daemon，sshfs進程通過讀取"/dev/fuse"設備檔案來獲得數據，如果pending queue為空，它將陷入阻塞等待：
當pending queue上有請求到來時，daemon進程將被喚醒並處理這些請求。被處理的請求會被移入processing queue，待daemon進程向fuse核心模組做出reply之後，user進程將被喚醒，對應的request將從processing queue移除。
【第二回合】
接下來就是執行"touch"指令時所觸發的其他系統調用，如果是之前訪問過的data/metadata，那很可能存在於cache中，再次訪問這部分data/metadata的時候，fuse內核模組就可以自行解決，不需要去用戶空間往返一趟，否則還是需要回報daemon進程進行處理。
這裡 get_fuse_conn() 取得的是在fuse類型的檔案系統被mount時建立的"fuse_conn"結構體實例。作為daemon進程和kernel聯繫的紐帶，除非daemon進程消亡，或對應的fuse檔案系統被卸載，否則該connection將一直存在。
在daemon進程這一端，還是類似的操作。需要注意的是區別 fuse_write/read() 和fuse_dev_write/read() 這兩個系列的函數，前者是user進程在存取fuse檔案系統上的檔案時的VFS讀寫請求，屬於對常規檔案的操作，而後者是daemon程序對"/dev/fuse"這個代表fuse核心模組的裝置的讀寫，目的是為了取得request和給予reply。
【第三輪】
fuse核心模組和daemon進程的最後一輪互動是在代表fuse檔案系統的superblock中取得inode號，並填寫這個metadata的相關資訊。
不難發現，在fuse檔案系統中，即便執行一個相對簡單的"touch"操作，所涉及的用戶態和內核態的切換都是比較頻繁的，並且還伴隨著多次的資料拷貝。相較於傳統的核心檔案系統，它整體的I/O吞吐量更低，而延遲也更大。
那為什麼fuse在作業系統支援的檔案系統裡面依然佔有一席之地呢？說起來，在使用者態開發是有很多優勢的。 一是方便調試，特別適合做一個新文件系統prototype的快速驗證，因此在學術研究領域頗受青睞。在核心裡面，你只能用C語言吧，到了用戶態，就沒那麼多限制了，各種函數庫，各種程式語言，都可以上。
二是核心的bug往往一言不合就導致整個系統crash（在虛擬化的應用中更為嚴重，因為宿主機的crash會導致其上面運行的所有虛擬機crash），而用戶態的bug所造成的影響相對有限一些。
所以，硬幣的正面是便於開發，不過到底有多方便，這畢竟是一種主觀的感受，而反面則是性能的影響，這可是能夠用客觀的實驗數據來驗證的。那應該用什麼方法才能相對精確地衡量fuse所帶來的損耗呢？
還是用前面用過的這個fuse-sshfs，不過這裡我們不再使用遠端掛載，而是採用本地掛載的方式（假設本機的"dir-src"目錄位於ext4文件系統）：
sshfs localhost:
當daemon進程收到請求後，它需要再次進入內核，去存取ext4的核心模組（這種檔案系統模式被稱為"stackable"的）：
#以user進程向fuse檔案系統發出write() 請求為例，右邊紅框部分是一次原生的ext4呼叫路徑，而左邊多出來的就是因為引入fuse後增加的路徑：
這篇文件給予的數據，在這一系統呼叫中使用到的"getxattr"所形成的request，需要2倍的"user-kernel"交互量。對於順序寫，相較於起原生的ext4檔案系統，I/O吞吐量降低27%，隨機寫入則降低44%。
不過，在fuse檔案系統誕生的這麼多年裡，大家還是為它想出了很多的優化舉措。例如，順序讀寫的時候，可以設計成向daemon程序批量發送request的形式（但隨機讀寫不適合）。 還有就是使用splicing這種zero-copy技術，由Linux核心提供的splicing機制允許用戶空間在轉移兩個核心的記憶體buffer的資料時，不需要拷貝，因此尤其適合在stackable模式下，從fuse核心模組直接傳遞資料到ext4核心模組（但splicing通常用於超過4K的請求，小資料量的讀寫用不上）。
經過這些努力，fuse檔案系統的效能可以達到什麼樣的一種程度呢？根據這篇報告列出的測試結果，相較於原生的ext4，在最理想的情況下，fuse的效能損耗可以控製到5%以內，但最差的情況則是83% 。同時，其對CPU的資源佔用也增加了31%。
從Android v4.4到v7.0之間存在的sdcard daemon，到近年來的Ceph和GlusterFS，都曾經採用過或正在採用基於FUSE的實作。 FUSE在network filesystem和虛擬化應用中都展現了自己的用武之地，它的出現和發展，並不是要取代在內核態實現的檔案系統，而是作為一個有益的補充（理論上，FUSE還可以用於實作根檔案系統，但是不建議這麼做，"can do"和"should do"是兩回事）。 相關推薦：《Linux影片教學》
以上是linux fuse是什麼意思的詳細內容。更多資訊請關注PHP中文網其他相關文章！
