特种文件系统(5)

9.5 其他特种文件系统

都说知足者常乐，但是往往就有那么一些人，以发现不足为己任，以满足不足为乐趣。于是就有了四大发明、有了飞机大炮、有了UNIX、有了Linux、有了你我今天所面对的世界。

9.5.1 RelayFS

我们做技术的，大多数人都是喜欢买书的，而且买过的书大多都不看。还遭到了信奉“书非借不能读”的人嘲弄。但是在工作中就会发现，那些嘲笑我们只买不看的人终于体会到了书到用时方恨少的苦楚，很快就加入到了我们这类人的行列。其实工具也一样。

前面已经介绍过了，procfs和sysfs是用户空间和内核空间交换数据的接口，但是不满足的人们总是觉得它们不够给力。因为从内核向用户空间反馈大量数据时，无论使用procfs还是sysfs都是很蹩脚的。IT界的民工们一直追求的就是高效可靠，越快越好。于是有一种叫RelayFS的文件系统就诞生了，它专门用来从内核空间向用户空间反馈大量数据的。不过最新的称呼，已经叫它relay了。我还在叫他RelayFS是因为我已经习惯了，改起来还需要一点时间。

在用户空间通过RelayFS从内核空间获取数据，是通过mmap来完成的。丰富经验Linux程序员一般都会了解mmap是读取大块数据的利器。这个在Windows系统中叫内存映射文件，其实在Linux中也可以这么叫它，把它理解为自实现的轻量化tmpfs可以，只是tmpfs人家是文件系统，mmap只能针对一个文件罢了，作用机制差不多，都是利用虚拟内存来提高文件访问效率的。本书后面会有更为详细的内容去介绍mmap的原理。

RelayFS有一个特点，用户空间与内核空间采用通道相连，数据就在通道中传递，要注意的是，这个通道是跟CPU一一对应的。它这么设计还是从性能方面考虑的。单CPU系统模型就很简单，但是到了多CPU时就立马变得复杂起来。简单一点说，因为每个CPU都有自己独立的L1和L2高速缓存。CPU能够读到数据的唯一来源，本质上是自身的高速缓存。如果高速缓存中没有需要的数据，就需要从内存中先复制到高速缓存。这个过程非常耗费CPU的时间，而且一直都出现缓存不命中的情况，整体效率将会非常低下。这个缓存对于应用程序，乃至操作系统都是透明的，谁都控制不了。在现行的SMP系统中，即对称式多CPU系统中，内存对于任何CPU都是共享的，任何一个CPU都可以访问内存中的任何一个位置。那么如果不能合理组织数据给不同的CPU就会出现问题。例如，当CPU0和CPU1都要访问同一内存的数据；如果都是读是没有问题的。但是当CPU0写这块数据时，实际上写的是它高速缓存内的数据，内存中的数据实际上没有变化。这时CPU1要读这部分数据会出现什么现象呢？CPU1中的缓存失效，不命中。内存中的数据失效，需要CPU0同步。于是CPU0要将刚才写过的数据同步回内存，CPU1将内存中的新数据装入缓存。在这个过程两颗CPU的工作效率还不如一颗。所以，RelayFS为了规避这种情况发生，数据通道采用跟CPU一一对应的关系。

9.5.2 debugfs

顾名思义，这就是用于调试用的。不过这个只是用于调试内核用的。应用程序员就不要打它的主意了。

debugfs是基于relay技术实现的。因为relay可已极快地将大量的内核空间数据反馈给用户空间，效率是远高于传统的printk的。所以使用debugfs可以获取更多的调试信息，且占用CPU资源更少。由于是基于文件系统的，使用起来会更加方便。毕竟它不会让你的屏幕乱糟糟。

最后说一句就是，想学习内核开发的，就开始使用debugfs吧，绝对是你的好帮手。

9.6 结束语

有关Linux特种文件系统的一些故事到此就算讲完了。类似devfs和sysfs这样的惊心动魄的江湖地位争夺战，在Linux世界无时无刻不在上演着。其实我不单单是希望大家通过对特种文件的了解而更明细的认识Linux，更希望的是通过这一个个案例，来展现Linux能够玉树常青的不二法则――新的系统并不是只为了做同样的事情比老的系统快一点，还应该允许我们用以前完全不可能的方法来处理事情，去感受Linux世界文化的深邃与博大。就像sysfs最终干掉了devfs。在Linux界是允许造反的，只要你能，我们就说：造反无罪，造反有理。