本文中要介紹一個所謂的"Linux 文件系統(tǒng)的守護神"，這是指一個能實時地觀察 Linux 文件系統(tǒng)的變化情況的程序模塊。能夠?qū)崟r的觀察文件系統(tǒng)的變化情況，并做出及時的適當?shù)姆磻?yīng)，這對于應(yīng)用 Linux 做桌面計算機系統(tǒng)來說，是十分的有趣，也是十分的重要的。本文還要介紹 Linux 文件系統(tǒng)的異步 I/O 的擴展。同樣，這對于 Linux 系統(tǒng)的桌面應(yīng)用也是關(guān)鍵的。 1、Linux 文件系統(tǒng)的守護神 傳統(tǒng)的 Linux 文件系統(tǒng)呈現(xiàn)給用戶程序的界面，確實是十分的干凈利落。用戶程序可以打開一個文件，向文件中線性的寫入數(shù)據(jù)，從文件的某一位置開始，線性的讀出數(shù)據(jù)，關(guān)閉一個文件，刪除一個文件，創(chuàng)建一個文件，等等。請看，只有這么若干個簡潔的操作原語，可是卻能提供這么多豐富的應(yīng)用。但是，我們注意到，用于訪問 Linux 的文件系統(tǒng)的這些操作原語，并沒有提供非常復雜的加鎖解鎖的功能。這是一件很奇妙的事情，如果來自不同的用戶程序的請求發(fā)生了沖突怎么辦呢？ 我們不妨走的再靠近一點，仔細的看看刪除一個文件是怎樣進行的。如果已經(jīng)有一個用戶程序在訪問一個文件，而另外一個用戶程序正好要刪除這一個文件，這時會發(fā)生些什么呢？我們知道，Linux 的文件系統(tǒng)是基于所謂的 inode 的，每個文件都相伴有一個 inode。在 inode 中記錄了關(guān)于這個文件的一些系統(tǒng)信息，比如文件的所有者，文件相關(guān)的一些權(quán)限記錄，關(guān)于文件的若干個時間戳，等等。在內(nèi)存中的 inode 還維持著一個關(guān)于自己的使用計數(shù)。每當一個 inode 所代表的文件被打開一次，這個 inode 就把關(guān)于自己的使用計數(shù)加一。每當這個 inode 所代表的文件一被關(guān)閉，這個 inode 就把關(guān)于自己的使用計數(shù)減一。當用戶程序刪除一個文件的時候，相關(guān)的系統(tǒng)調(diào)用很快就返回到這個用戶程序，告訴它，相應(yīng)的文件已經(jīng)被刪除了。但是相應(yīng)的 inode 還是保留在系統(tǒng)中，inode 首先要檢查自己的使用計數(shù)，如果使用計數(shù)為零，那么 Linux Kernel 才可以真正的去刪除這個文件。如果使用計數(shù)大于零，也就是說，還有其它的用戶程序在訪問這一個文件，那么 Linux Kernel 需要等待這些其他的用戶程序一個個都完成對這一個文件的訪問才行。也就是說，要等到這個 inode 的使用計數(shù)掉到零，才能真正的去刪除這一個文件。 我們可以設(shè)想一下，如果有一個 MP3 播放程序在播放一首 MP3 音樂，我們覺得它不好聽，就到硬盤上找到這個文件，把它 rm 掉了。這時候，MP3 播放程序并不受到影響，還是可以繼續(xù)播放這首 MP3 音樂，雖然這時候在文件系統(tǒng)上用 ls 已經(jīng)找不到這個 MP3 音樂文件了。實際上，一直要到 MP3 播放程序停止播放這首 MP3 音樂，然后 Linux 文件系統(tǒng)才真正的從硬盤上刪除這個 MP3 文件。這個經(jīng)驗和我們在 Windows 平臺上遇到的截然不同。 在 Windows 平臺上，當我們試圖在文件夾窗口中用鼠標點擊右鍵菜單刪除 Winamp 正在播放的一首 MP3 音樂的時候，Windows 系統(tǒng)會用一個彈出對話框告訴我們，這個文件正在被使用，沒辦法刪除。Windows 系統(tǒng)的關(guān)于刪除文件的這樣一個解釋，如果使用不當?shù)脑?，會帶來一個滑稽可笑的問題。我們可以設(shè)想一下，用戶的一個 P2P 的文件共享程序提供了一個 MP3 文件以供別人下載，恰巧這個 MP3 音樂文件十分的熱門，不斷的有人來下載，這個用戶最終決定要節(jié)省一下帶寬，想要把這個 MP3 音樂文件刪除掉，但是 Windows 系統(tǒng)卻不允許用戶這樣做，因為這個 P2P 的文件共享程序總是在使用這個 MP3 文件。用戶要想刪除這個文件，不得不先把 P2P 的文件共享程序給停下來！呵呵。 但是 Linux 的文件系統(tǒng)的操作原語也有它自己的問題。我們知道，在一個 Linux Shell 的命令行上，先 rm，然后再 ls，非常的干凈，被 rm 的文件沒有了，被刪除了。但是我們可以設(shè)想有一個圖形界面的文件管理程序，當用戶從 Shell 的命令行上 rm 掉一個文件的時候，這個圖形界面的文件管理程序并沒有收到任何人發(fā)給它的任何消息，它還以為什么都沒有發(fā)生，被刪除掉的文件還在那兒。這實在是很 U.G.L.Y. 啊。 那么要想解決這個問題，一個明顯的但是非常不好的辦法，就是讓一個后臺進程 Daemon 每隔一個很短的時間間隔，就檢查一下文件系統(tǒng)上這個目錄的情況，看看有沒有發(fā)生什么變化。這個辦法的缺點真的是顯而易見的，不但系統(tǒng)的性能受到影響，而且它的反應(yīng)也還不是實時的。 如果我們需要用戶程序能夠?qū)崟r地了解文件系統(tǒng)上某一個目錄的變化情況，從實時這個角度出發(fā)，顯然，我們需要有一個中斷機制。我們都知道，硬件中斷能夠?qū)崟r地把系統(tǒng)某一個部件的情況反映給中央處理器，同樣的，要想把位于系統(tǒng)內(nèi)核中的文件系統(tǒng)的情況實時地反映給用戶程序，我們也需要一個由操作系統(tǒng)內(nèi)核到達用戶進程的軟件中斷機制。熟悉 Linux 系統(tǒng)編程的讀者朋友們立即就會想到，這個中斷機制在 Linux 系統(tǒng)中早已就有了，這就是信號傳遞 signal。 找到了信號傳遞這樣一個中斷用戶進程的機制，一切似乎都已齊備，看來可以動手實現(xiàn)這樣一個 Linux 文件系統(tǒng)的守護神，來實時地監(jiān)視文件系統(tǒng)的變化情況，并且及時地把消息通知給用戶程序了。不過且慢，讓我們搜索一下 Linux Kernel，看看是否有別人也在做同樣的工作。哈哈，果不其然，原來這樣一個實時地監(jiān)視文件系統(tǒng)情況的機制早已在 Linux 內(nèi)核中實現(xiàn)了。下面一段就是取自 Linux Kernel 文檔的一段小小例程，說明了 Linux Kernel 中的 dnotify 功能的用法。dnotify 就是指 directory notification，監(jiān)視文件系統(tǒng)上一個目錄中的情況。 #define _GNU_SOURCE     /* needed to get the defines */
#include <fcntl.h>      /* in glibc 2.2 this has the needed
values defined */
#include <signal.h>
#include <stdio.h>
#include <unistd.h>

static volatile int event_fd； // 信號處理例程    
static void handler(int sig, siginfo_t *si, void *data)
{
event_fd = si->si_fd；
}

int main(void)
{
struct sigaction act；
int fd；

// 登記信號處理例程
act.sa_sigaction = handler；
sigemptyset(&act.sa_mask)；
act.sa_flags = SA_SIGINFO；
sigaction(SIGRTMIN, &act, NULL)；

// 需要了解當前目錄"."的情況
fd = open(".", O_RDONLY)；
fcntl(fd, F_SETSIG, SIGRTMIN)；
fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT)；
/* we will now be notified if any of the files
in "." is modified or new files are created */
while (1) {
// 收到信號后，就會執(zhí)行信號處理例程。
// 而 pause() 也就結(jié)束了。
pause()；
printf("Got event on fd=%d\n", event_fd)；
}
} 上面這一小段例程，對于熟悉 Linux 系統(tǒng)編程的讀者朋友們來說，是很容易理解的。程序首先注冊一個信號處理例程，然后通知 Kernel，我要觀察 fd 上的 DN_MODIFY 和 DN_CREATE 和 DN_MULTISHOT 事件。（關(guān)于這些事件的詳細定義，請讀者朋友們參閱文后所列的參考資料。） Linux Kernel 收到這個請求后，把相應(yīng)的 fd 的 inode 給做上記號，然后 Linux Kernel 和用戶應(yīng)用程序就自顧自去處理各自的別的事情去了。等到 inode 上發(fā)生了相應(yīng)的事件，Linux Kernel 就把信號發(fā)給用戶進程，于是開始執(zhí)行信號處理例程，用戶程序?qū)ξ募到y(tǒng)上的變化也就可以及時的做出反應(yīng)了。而在這整個過程中，系統(tǒng)以及用戶程序的正常運行基本上未受到性能上的影響。這里還需要說明的是，dnotify 并沒有通過增加新的系統(tǒng)調(diào)用來完成它的功能，而是通過 fcntl 來完成任務(wù)的。增加一個系統(tǒng)調(diào)用，相對來說是一個很大的手術(shù)，而且如果設(shè)計不當，處理得不好的話，傷疤會一直留在那里，這是 Linux Kernel 的開發(fā)者們所非常不愿意見到的事情。 2、Linux 文件系統(tǒng)的異步 I/O 擴展 對于桌面計算機系統(tǒng)來說，能夠快速的響應(yīng)用戶的請求，這也是十分關(guān)鍵的。換句話說，當用戶移動鼠標的時候，不管系統(tǒng)正在進行什么天大的、重要的、神圣的、不可打斷的工作，它都得立即停下，并且要讓鼠標立即流暢的在計算機屏幕上完美地運動起來。對于習慣在傳統(tǒng)的 Linux 命令行上工作的讀者朋友們來說，讓鼠標能夠在任何時間都可以在計算機屏幕上向無頭蒼蠅一樣地亂竄，竟然被當成是最重要的系統(tǒng)任務(wù)，這實在有一點讓人難以接受。不過，當你從 Linux 命令行上轉(zhuǎn)移到 GNOME 或者 KDE 這樣的圖形界面的用戶環(huán)境的時候，鼠標被鎖死，百分之百的也是會讓你失去理智的。所以，還是讓我們接受這一個現(xiàn)實，看一看如何才能增加系統(tǒng)的響應(yīng)速度吧。 從文件系統(tǒng)的角度講，特別是考慮到網(wǎng)絡(luò)文件系統(tǒng)，它的響應(yīng)速度有可能會相當?shù)穆?。當用戶在文件管理程序中，選擇了對文件進行某一個操作以后，文件系統(tǒng)可能會需要相當長的時間，才能完成這一操作。如果文件管理程序必須要等待文件系統(tǒng)完成這一操作，然后才能繼續(xù)的話，這顯然會給文件管理程序的用戶帶來非常不愉快的經(jīng)歷。解決這一個問題的辦法，就是要實現(xiàn)異步的文件系統(tǒng) I/O。 在 Linux 的 Gnome 桌面環(huán)境中，由 GnomeVFS 包裹了真正的 Linux 文件系統(tǒng) I/O，實現(xiàn)了一個異步的文件系統(tǒng) 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 例程之后，函數(shù)調(diào)用就立即返回給用戶程序，用戶程序就可以處理自己的別的事情去了，比如進一步響應(yīng)來自用戶的其??肭螅?鵲?。?蔽募?低懲瓿啥暈?zāi)?拇蚩?僮饕院螅珿nomeVFS 就會調(diào)用剛剛注冊的 call back 例程，通知用戶程序，文件已經(jīng)打開。 3、小結(jié) 我們在本文中了解了 Linux Kernel 中的 dnotify，可以幫助我們實時地監(jiān)視文件系統(tǒng)目錄樹中的變化情況；也了解了 Gnome 桌面環(huán)境的 GnomeVFS 異步文件系統(tǒng) I/O 擴展；可以幫助用戶程序不至于被文件系統(tǒng)的請求所 Block。這兩個功能對于 Linux 系統(tǒng)在桌面上的應(yīng)用都是很重要的。