?

　　本文中要介紹一個所謂的"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 的開發者們所非常不愿意見到的事情。