最近项目用到了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/