Linux文件系统的异步I/O扩展

 

　　本文中要介绍一个所谓的"Linux 文件系统的守护神"，这是指一个能实时地观察 Linux 文件系统的变化情况的程序模块。

　　能够实时的观察文件系统的变化情况，并做出及时的适当的反应，这对于应用 Linux 做桌面计算机系统来说，是十分的有趣，也是十分的重要的。本文还要介绍 Linux 文件系统的异步 I/O 的扩展。同样，这对于 Linux 系统的桌面应用也是关键的。

　　1 Linux 文件系统的守护神

　　传统的 Linux 文件系统呈现给用户程序的界面，确实是十分的干净利落。用户程序可以打开一个文件，向文件中线性的写入数据，从文件的某一位置开始，线性的读出数据，关闭一个文件，删除一个文件，创建一个文件，等等。请看，只有这么若干个简洁的操作原语，可是却能提供这么多丰富的应用。但是，我们注意到，用于访问 Linux 的文件系统的这些操作原语，并没有提供非常复杂的加锁解锁的功能。这是一件很奇妙的事情，如果来自不同的用户程序的请求发生了冲突怎么办呢?

　　我们不妨走的再靠近一点，仔细的看看删除一个文件是怎样进行的。如果已经有一个用户程序在访问一个文件，而另外一个用户程序正好要删除这一个文件，这时会发生些什么呢?我们知道，Linux 的文件系统是基于所谓的 inode 的，每个文件都相伴有一个 inode。在 inode 中记录了关于这个文件的一些系统信息，比如文件的所有者，文件相关的一些权限记录，关于文件的若干个时间戳，等等。在内存中的 inode 还维持着一个关于自己的使用计数。每当一个 inode 所代表的文件被打开一次，这个 inode 就把关于自己的使用计数加一。每当这个 inode 所代表的文件一被关闭，这个 inode 就把关于自己的使用计数减一。当用户程序删除一个文件的时候，相关的系统调用很快就返回到这个用户程序，告诉它，相应的文件已经被删除了。但是相应的 inode 还是保留在系统中，inode 首先要检查自己的使用计数，如果使用计数为零，那么 Linux Kernel 才可以真正的去删除这个文件。如果使用计数大于零，也就是说，还有其它的用户程序在访问这一个文件，那么 Linux Kernel 需要等待这些其他的用户程序一个个都完成对这一个文件的访问才行。也就是说，要等到这个 inode 的使用计数掉到零，才能真正的去删除这一个文件。

　　我们可以设想一下，如果有一个 MP3 播放程序在播放一首 MP3 音乐，我们觉得它不好听，就到硬盘上找到这个文件，把它 rm 掉了。这时候，MP3 播放程序并不受到影响，还是可以继续播放这首 MP3 音乐，虽然这时候在文件系统上用 ls 已经找不到这个 MP3 音乐文件了。实际上，一直要到 MP3 播放程序停止播放这首 MP3 音乐，然后 Linux 文件系统才真正的从硬盘上删除这个 MP3 文件。这个经验和我们在 Windows 平台上遇到的截然不同。

　　在 Windows 平台上，当我们试图在文件夹窗口中用鼠标点击右键菜单删除 Winamp 正在播放的一首 MP3 音乐的时候，Windows 系统会用一个弹出对话框告诉我们，这个文件正在被使用，没办法删除。Windows 系统的关于删除文件的这样一个解释，如果使用不当的话，会带来一个滑稽可笑的问题。我们可以设想一下，用户的一个 P2P 的文件共享程序提供了一个 MP3 文件以供别人下载，恰巧这个 MP3 音乐文件十分的热门，不断的有人来下载，这个用户最终决定要节省一下带宽，想要把这个 MP3 音乐文件删除掉，但是 Windows 系统却不允许用户这样做，因为这个 P2P 的文件共享程序总是在使用这个 MP3 文件。用户要想删除这个文件，不得不先把 P2P 的文件共享程序给停下来!

　　但是 Linux 的文件系统的操作原语也有它自己的问题。我们知道，在一个 Linux Shell 的命令行上，先 rm，然后再 ls，非常的干净，被 rm 的文件没有了，被删除了。但是我们可以设想有一个图形界面的文件管理程序，当用户从 Shell 的命令行上 rm 掉一个文件的时候，这个图形界面的文件管理程序并没有收到任何人发给它的任何消息，它还以为什么都没有发生，被删除掉的文件还在那儿。这实在是很 U.G.L.Y. 啊。

　　上面这一小段例程，对于熟悉 Linux 系统编程的读者朋友们来说，是很容易理解的。程序首先注册一个信号处理例程，然后通知 Kernel，我要观察 fd 上的 DN_MODIFY 和 DN_CREATE 和 DN_MULTISHOT 事件。(关于这些事件的详细定义，请读者朋友们参阅文后所列的参考资料。) Linux Kernel 收到这个请求后，把相应的 fd 的 inode 给做上记号，然后 Linux Kernel 和用户应用程序就自顾自去处理各自的别的事情去了。等到 inode 上发生了相应的事件，Linux Kernel 就把信号发给用户进程，于是开始执行信号处理例程，用户程序对文件系统上的变化也就可以及时的做出反应了。而在这整个过程中，系统以及用户程序的正常运行基本上未受到性能上的影响。这里还需要说明的是，dnotify 并没有通过增加新的系统调用来完成它的功能，而是通过 fcntl 来完成任务的。增加一个系统调用，相对来说是一个很大的手术，而且如果设计不当，处理得不好的话，伤疤会一直留在那里，这是 Linux Kernel 的开发者们所非常不愿意见到的事情。