能够实时的观察文件系统的变化情况，并做出及时的适当的反应，这对于应用 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 的开发者们所非常不愿意见到的事情。

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

对于桌面计算机系统来说，能够快速的响应用户的请求，这也是十分关键的。换句话说，当用户移动鼠标的时候，不管系统正在进行什么天大的、重要的、神圣的、不可打断的工作，它都得立即停下，并且要让鼠标立即流畅的在计算机屏幕上完美地运动起来。对于习惯在传统的 Linux 命令行上工作的读者朋友们来说，让鼠标能够在任何时间都可以在计算机屏幕上向无头苍蝇一样地乱窜，竟然被当成是最重要的系统任务，这实在有一点让人难以接受。不过，当你从 Linux 命令行上转移到 GNOME 或者 KDE 这样的图形界面的用户环境的时候，鼠标被锁死，百分之百的也是会让你失去理智的。所以，还是让我们接受这一个现实，看一看如何才能增加系统的响应速度吧。

从文件系统的角度讲，特别是考虑到网络文件系统，它的响应速度有可能会相当的慢。当用户在文件管理程序中，选择了对文件进行某一个操作以后，文件系统可能会需要相当长的时间，才能完成这一操作。如果文件管理程序必须要等待文件系统完成这一操作，然后才能继续的话，这显然会给文件管理程序的用户带来非常不愉快的经历。解决这一个问题的办法，就是要实现异步的文件系统 I/O。

在 Linux 的 Gnome 桌面环境中，由 GnomeVFS 包裹了真正的 Linux 文件系统 I/O，实现了一个异步的文件系统 I/O 接口 API。我们可以看到下面这个用 GnomeVFS 打开文件的例子。

enum _GnomeVFSOpenMode {

GNOME_VFS_OPEN_NONE = 0,

GNOME_VFS_OPEN_READ = 1 << 0,

GNOME_VFS_OPEN_WRITE = 1 << 1,

GNOME_VFS_OPEN_RANDOM = 1 << 2

};

typedef enum _GnomeVFSOpenMode GnomeVFSOpenMode;

typedef void (* GnomeVFSAsyncOpenCallback)

(GnomeVFSAsyncHandle *handle,

GnomeVFSResult result,

gpointer callback_data);

GnomeVFSResult gnome_vfs_async_open

(GnomeVFSAsyncHandle **handle_return,

const gchar *text_uri,

GnomeVFSOpenMode open_mode,

GnomeVFSAsyncOpenCallback callback,

gpointer callback_data);

我们注意到，上面的代码段中，用户程序为了打开一个文件，向 GnomeVFS 注册了一个 call back 例程。在注册了这一个 call back 例程之后，函数调用就立即返回给用户程序，用户程序就可以处理自己的别的事情去了，比如进一步响应来自用户的其??肭螅?鹊取６?蔽募?低惩瓿啥晕募?拇蚩?僮饕院螅珿nomeVFS 就会调用刚刚注册的 call back 例程，通知用户程序，文件已经打开。

3 小结

我们在本文中了解了 Linux Kernel 中的 dnotify，可以帮助我们实时地监视文件系统目录树中的变化情况；也了解了 Gnome 桌面环境的 GnomeVFS 异步文件系统 I/O 扩展；可以帮助用户程序不至于被文件系统的请求所 Block。这两个功能对于 Linux 系统在桌面上的应用都是很重要的。