分佈式文件系統中的類Inotify功能

Question

正如標題所示，我想在發生某些事件時觸發通知。

上述事件可以由用戶定義，如updating specified files in 1-miniute。

如果文件被存儲在本地，我可以很容易地將其與系統調用inotify做，但情況是，文件查找的分佈式文件系統，如MFS上..

如何製作的？我想知道是否有解決方案或開源項目來解決這個問題。謝謝。

Answer 1

如果您只有對遠程系統的黑匣子訪問權限（例如NFS協議），那麼除非協議支持您所需的內容，否則沒有多少選項。所以我假設你可以控制遠程系統。

「微不足道」的方法是在每臺將通過網絡轉發通知的計算機上運行本地inotify/fanotify偵聽器。 FAM can do this over NFS。

所有基於通知的系統的問題是在各種邊緣情況下丟失通知的風險。這在網絡上變得更加尖銳 - 例如客戶端確認收到通知，然後立即崩潰。有可靠的消息隊列，你可以建立在但恕我直言這樣瘋狂的謊言......

一個理智的做法是無狀態的基於散列的掃描。

我喜歡稱以下設計爲「hnotify」，但這不是一個既定的術語。這些想法被許多版本控制和備份系統廣泛使用，可追溯到Plan 9。

的核心思想是，如果你知道文件的加密哈希，您可以撰寫，表示文件的目錄中的一個哈希 - 它改變如果文件的任何改變 - 你可以建造這些自下而上的代表整個文件系統的狀態。
（Git stores things this way並且效率很高。）

哈希樹爲什麼很酷？如果你有2棵哈希 - 一個代表你過去，一個代表當前狀態的點看到文件系統的狀態 - 你可以很容易地找出它們之間有什麼改變：

1. 你開始的根。如果它們不同，則閱讀2個根目錄併爲子目錄比較散列值。
2. 如果一個子目錄在兩棵樹中都有相同的散列，那麼就沒有其他它改變了。沒有意義去那裏。
3. 如果子目錄的散列值發生變化，則遞歸比較其內容 - 調用步驟（1）。
4. 如果有一個子目錄另一個沒有，那麼這是一個變化。藉助一些全局表格，您還可以檢測移動/重命名。

請注意，如果少數文件發生更改，您只能讀取當前狀態的一小部分。因此，遠程系統不必向您發送整個哈希樹，它可以是「爲此目錄提供哈希值的交互式乒乓球;現在可以爲此...」。
（這類似於如何Git的愚蠢的http協議worked; there is a newer協議與較少的往返旅程。）

這就像輪詢整個文件系統以進行更改一樣穩健和防錯 - 您不會錯過任何內容 - 但效率相當高！

但是，服務器如何跟蹤當前哈希？

不幸的是，對於大多數人來說，完全散列所有磁盤寫入操作都太昂貴了。如果幸運的話，您可以免費獲得重複數據刪除文件系統，例如， ZFS或Btrfs。
否則，你會被迫重讀所有已更改的文件（這比在文件系統層中更加昂貴），或者使用虛假文件哈希：對文件進行任何更改時，發明新的隨機「哈希」使其無效（並嘗試保持虛假的散列）。仍然計算真正的哈希樹。現在，您可能會有誤報 - 當內容相同時，您會「發現變更」 - 但絕不會出現漏報。

無論如何，關鍵在於無論你做什麼有狀態的攻擊（例如週期性掃描確定），你只能在服務器上本地執行。在整個網絡中，你只發送表示當前狀態（或其子樹）快照的散列！通過這種方式，您可以擁有包含許多服務器和客戶端的分佈式系統，間歇性連接，並且仍然保持您的理智。

P.S. Btrfs可以efficiently find differences from an older snapshot。但是這是服務器上的快照（並且導致所有數據被保留！），比客戶端輕量級哈希樹更不靈活。

P.S.其中一個標籤是HadoopFS。我並不是很熟悉它，但我懷疑它的很多文件是一次寫入然後不可變的，它可能本能地給你一些可以用作假哈希的文件/塊ID。

現有的工具

• 該彈在我看來是bup index的第一個工具。 bup是一個非常聰明的基於git的重複數據刪除備份工具（只能擴展到大數據），因此它位於上述基礎之上。理論上，通過在服務器上建立bup數據並在網絡上執行git fetch，甚至可以對我之前描述的新功能進行散列比較 - 不幸的是，bup產生的git存儲庫對於git本身來說太大了以至於無法應付。你也許不希望bup讀取和存儲你的所有數據。但是bup index是一個獨立的子系統，它可以快速掃描文件系統以查找潛在的更改，而不必讀取已更改的文件。
  目前bup不使用inotify，但它是discussed in depth。

  噢，bup使用布盧姆過濾器，這是一種近似最佳的方式來表示具有誤報的集合。我幾乎可以肯定布盧姆過濾器可以在優化無狀態通知協議中發揮作用（「這裏是我所有的壓縮位圖;你應該能夠縮小你的查詢的範圍」或「這裏是我的壓縮位圖想要被通知「）。不知道the way bup uses them對你是否有用，但是這個數據結構肯定應該在你的工具帶中。其他工具是git annex。它也基於Git（你注意到了一種趨勢？），但是它旨在保持數據本身不受Git回購（因此git fetch應該可以工作！）並且具有使用假散列來提高性能的"WORM" option。

替代設計：壓縮可玩性雜誌

我曾經以爲上面的是爲客戶檢查有什麼變化，唯一理智的無狀態的方法。但我剛剛讀了關於OS X的FSEvents框架的http://arstechnica.com/apple/2007/10/mac-os-x-10-5/7/，它有一個可能更簡單的設計：

• 所有更改都記錄到文件。它永遠存在。
• 客戶可以問「重播我的一切，因爲事件51348」。
• 的魔術是日誌有粗粒度（「這個目錄改變了一些東西，去重新掃描，以找出什麼」，在30秒內反覆變化組合），所以這個日誌文件是非常緊湊。

在較低水平，你可能會採取類似的技術 - 例如散列 - 但頂級界面是不同的：而不是你處理事件時間線的快照。對某些應用來說這可能更容易。