我的头脑里有一个图像，链接太慢，无法实现文件的实时传输，但速度足够快，可以赶上每天。 我想看到的是一个主要的主设备，当我向服务器A写入一个文件时，元数据将立即传输到服务器B，并且当服务器B的客户端尝试读取服务器A发送它之前的文件。
似乎有很多文件系统可以在快速链接上运行得很好，但是我不知道有什么好的做法能够解决瓶颈问题和几个小时的延迟问题。
glusterfs有一个治疗模式，就像你描述的一样。 它会共享元数据，但只能“修复”访问时的文件副本。 “夜间同步”过程被logging为：
find /mountpoint -type f -print0 | xargs -0 head -c1 应有的警告：我希望特定的function仍然可用，但我一年没有使用它。
Soooo …你遇到的问题是当A方的某个人想要一个写在B面上的文件但是还没有同步的时候你该怎么做？
有一个原因是为什么共享文件系统在快速链接上工作得很好 – 可以为他们的操作定义标准语义，这种语义可以很好地映射到我们都知道并喜爱的标准POSIX文件系统语义。 任何并不是所有数据都实际可用的东西几乎立即落入“特定于领域”的领域 – 您对文件系统的使用情况可能是这样的，您不必担心数据丢失（有效追加 -只有数据存储，或者可以通过重新计算或者欺骗结果来有效地处理缺失数据的数据存储），但这些并不是常见的情况（并且很难build模，指定等），以至于没有人困扰于写一些大家都可以使用的通用目的。