最近項目用到了Fuse“秒級”準備代碼，構建時按需從遠程獲取代碼並緩存到本地。雖然代碼“準備”確實是快了，但構建的速度卻有40%左右的劣化，正如下午說的，每次讀寫文件都需要用戶態和內核態的切換。當前能想到的是讀寫分離，即寫的目錄不要是fuse目錄，其他的辦法還得在研究。。。。
https://www.jianshu.com/p/c2b77d0bbc43
爲什麼FUSE會存在
事物的存在的原因之一是其優勢大於劣勢，下面是它的優劣描述。
優勢
- 文件系統的改動不用更新內核
FUSE的核心邏輯在用戶空間，所以修改文件系統的行爲絕大部分修改會在用戶空間。這在很多場合是一件很方便的事情。 - 很容易實現自己的文件系統
理論上它可以實現任何天馬行空的文件系統，只要一個開發者實現了基本的文件操作。而這個所謂的文件操作也是自己定義的，甚至可以這個操作可能只是一句打印而已，或者是一件超級複雜的事情，只要這個操作符合開發者的要求，他就完成了一個符合開發者需求的文件系統（也許本質上並不是文件系統了，這種情況是有現實例子的）。
劣勢
- 效率較低
這是顯而易見的，就針對塊設備的文件系統而言，用戶層肯定不如內核實現的效率高，畢竟用戶態/內核態切換的開銷是少不了的。這也是符合一般軟件規律的，越高層次的軟件易用性越高，效率越低。
FUSE實現原理
下面這張圖體現了FUSE工作的基本套路，是根據WIki裏的畫的，這張圖感覺更符合我看到的代碼的狀況。
fuse基本工作流程
圖中體現了FUSE的2個關鍵部分（綠色方框），分別是Kernel中的那個FUSE(這裏簡稱kernel FUSE)和user space中的那個fuse_user程序。其中kernel FUSE是負責把從用戶層過來的文件系統操作請求傳遞給fuse_user程序的，而這個fuse_user程序實現了前面所說的文件系統的核心邏輯。
下面分步描述一下在用戶對一個FUSE分區上的文件執行ls命令時發生了什麼，當然，這裏隱含了個前提，即這個系統的/tmp目錄已經屬於某個FUSE分區了，爲了達到這種狀況，前面還需要有一個mount的過程
學習一個FUSE的helloworld吧：
http://www.maastaar.net/fuse/linux/filesystem/c/2016/05/21/writing-a-simple-filesystem-using-fuse/