分布式文件系统中的类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秒内反复变化组合），所以这个日志文件是非常紧凑。

在较低水平，你可能会采取类似的技术 - 例如散列 - 但顶级界面是不同的：而不是你处理事件时间线的快照。对某些应用来说这可能更容易。