我需要设置一个应用程序来监视在本地或网络驱动器上的目录中创建的文件。

或轮询FileSystemWatcher计时器将是最好的选择。我过去使用过这两种方法，但没有广泛使用。

这两种方法都有哪些问题（性能、可靠性等）？

如此多的选项，而测试它们的时间却如此之少......我想知道是否有人对用于视频流和存储/编码的分布式文件系统有经验。

我有很多巨大的视频文件（50GB 到 250GB）需要存储在某个地方，能够将它们编码为 mp4 并从多个 Adob​​e FMS 服务器流式传输它们。处理这一切的唯一方法是使用分布式文件系统，但现在的问题是哪个？

到目前为止，我的研究告诉我：

• Lustre：成熟成熟的解决方案，被很多大公司使用，最好是大于 10G 的文件是内核驱动程序。
• Gluster：新的，不太成熟的，基于 FUSE 的，这意味着易于安装，但由于 FUSE 开销可能会更慢。更好地处理大量较小的文件 ~1GB
• MogileFS : 似乎只适用于小文件~MB，使用 HTTP 访问？？未来可能的 FUSE 绑定。

到目前为止，Lustre 似乎是赢家，但我想听听我所拥有的特定应用程序的真实体验。

Hadoop、Redhat GFS、Coda 和 Windows DFS 听起来也可以作为选项，因此欢迎任何体验。如果有人有基准，请分享。

经过一些实际经验，这是我学到的：

• 光泽：
  • 性能：惊人的快！我可以断言 Lustre 可以提供大量流，并且编码速度不受通过 Lustre 访问文件的影响。
  • POXIS 兼容性：非常好！无需修改应用程序即可使用光泽。
  • 复制、负载平衡和故障转移：非常糟糕！对于复制负载平衡，我们和故障转移需要依赖其他软件，例如虚拟 IP 和 DRDB。
  • 安装：最糟糕的！普通人无法安装。需要内核、光泽补丁和调整的非常特定的组合才能使其正常工作。而当前的 luster 补丁通常适用于与新硬件/软件不兼容的旧内核。
• MogileFS：
  • 性能：适用于小文件，但不适用于大中型文件。这主要是由于 HTTP 开销，因为所有文件都是通过 HTTP 请求发送/接收的，这些请求将所有数据编码为 base64，为每个文件增加了 33% 的开销。
  • POXIX 兼容性不存在。所有应用程序都需要修改为使用 mogilefs，这使得它无法用于流式传输/编码，因为大多数流式传输服务器和编码工具不理解 MogileFS 协议。
  • 通过一次访问多个跟踪器，可以在应用程序中实现开箱即用的复制和故障转移以及负载平衡。
  • 安装相对容易，大多数发行版中都存在现成的软件包。我发现的唯一困难是设置数据库主从以消除单点故障。
    • 光泽：
  • 性能：对流媒体非常不利。在 10Gbps 网络中，我无法达到超过几 Mbps。客户端和服务器 CPU 因大量写入而猛增。对于编码工作，因为 CPU 在网络和 I/O 之前就已经饱和。
  • POXIS：几乎兼容。我使用的工具可以将 gluster 挂载作为磁盘中的普通文件夹访问，但在某些边缘情况下，事情会开始导致问题。检查 gluster 邮件列表，你会发现有很多问题。
  • 复制、故障转移和负载平衡：最好的！如果他们真的工作。Gluster 是非常新的，它有很多错误和性能问题。
  • 安装太容易了。管理命令行非常棒，在多台服务器之间设置复制、条带化和分布式卷再简单不过了。

定论：

不幸的是，结论是“没有银弹”。

目前，我们将 Gluster3.2 中的媒体文件放在一个复制卷中，用于存储和转码。只要您没有很多服务器，就可以避免异地复制和条带卷。

当我们要流式传输媒体文件时，我们将它们复制到一个光泽卷，该卷通过 DR:DB 复制到第二个光泽卷。然后 wowza 服务器从 luster 卷中读取媒体文件。

最后，我们使用 MogileFS 在我们的 Web 应用程序服务器中提供缩略图。

据我了解，分片（例如在 MongoDB 中）和分布式文件系统（例如 HBase 或 HyperTable 中的 HDFS）是数据库用于横向扩展的不同机制，但是我想知道它们如何比较？

TL;博士：

我想为 avg 提供分布式键值存储的建议。条目大小最大为 50KB，可安装在 Linux 环境（专用服务器）上。
文件系统解决方案就可以了。
我找到了一些解决方案：Ceph、Cassandra、Riak 等等。

细节

我正在为我们的一个组件寻找一种存储解决方案，它应该是一个键值存储、平面命名空间。

设想

读/写模式非常简单：

写入键值后，在接下来的几个小时内会进行几次读取。

之后，没有任何东西触及给定的键值。我们想保留这些数据以供将来使用，“存储模式”。

其他使用方面

• 操作系统：Linux
• Python 客户端/连接器
• 总大小：最大 80TB（这个值也代表未来的需求）。
• 平均条目大小（对于 kv 对中的单个值）：10 到 50 KB，未压缩，主要是文本数据
• 压缩：内置或外置。
• 加密：不需要
• 网络带宽：1Gb，单局域网
• 服务器：专用（不在云中）

最重要的要求

“基本”要求是：

• 操作系统：Linux
• Python 客户端/连接器或通过 HTTP 的 RESTful API
• 可以轻松存储高达 80TB（这个数值也代表未来的需求）。
• 最大读取延迟：第一次读取几秒，“存储模式”30 秒（见上文解释）
• 内置复制（以便数据存储在多个节点上）

很高兴有

• RESTful 网关
• 后台数据备份到另一个存储（用于在发生灾难时进行数据恢复）。
• 易于配置

到目前为止我发现了什么

• 头孢
• 高密度文件系统
• HDFS 之上的 HBase
• 光泽
• GlusterFS
• Mongo 的 GridFS - 但我可以信任 Mongo 的基础架构吗？
• Cassandra - 不是一个选项，因为合并过程消耗双倍磁盘大小
• Riak - 看起来和 Cassandra 有同样的问题，需要更多的研究
• Swift + OpenStack（实际存储可以在 Amazon S3 上）
• 伏地魔
• 还有几十个附加工具，但我不会在这里写它们，因为其中一些具有专有许可证，而另一些似乎不成熟。

对于我上面提到的任何工具（总容量超过 50TB）或您认为足够的工具，我将不胜感激。

我正在尝试为 android OS 开发一个无服务器分布式文件系统（类似于 Dropbox 但无服务器的功能）。我正在寻找有关如何处理它的建议。我在 android 上看到了 FUSE，但没有清楚地了解它如何帮助我的事业。我看到了一个名为 mobiDFS 的现有系统，但没有得到任何有关它的信息。请为我提供一些教程、论文或现有解决方案以帮助我入门。谢谢。

复活节快乐！

我正在用 C++ 编写分布式文件系统。而且，为了完全控制它，我编写了自己的 RPC。这个 RPC 框架的最后一个悬而未决的问题是反射，因为 C++ 没有提供它。

我知道 KFS 是用 c++ 编写的 DFS，但我不知道它的实现，所以我求助于各位善良和知识渊博的人。

我想它可能有一些方法来处理它的 RPC，不是吗？它是否以某种方式使用反射？如果它不使用反射，是否有任何其他基于 c++ 的分布式应用程序使用它。他们如何使用它？

请随时提出建议，我喜欢想法。

干杯，埃尔顿

Ceph有没有人在 CentOS 5 上成功编译？

中的第 1115 行src/Makefile.am：

我试图将其更改docdir为绝对路径：

但这无济于事。

令我惊讶的是ceph.spec，我看到：

--docdir但是在搜索时没有配置选项./configure --help。

我知道 CentOS 5 已经很老了，但是在这种情况下有什么解决方法吗？

更新星期四 4 月 4 日 23:05:53 ICT 2013

Ceph 0.46 编译成功，但现在我得到：

http://tracker.ceph.com/issues/4286

由于这个问题，我的朋友找到了包含ceph的Open Fusion存储库。

ceph-fuse安装没有问题：

但是安装时出现以下错误：

有人熟悉 Ceph 吗？我现在能做什么？

我的问题是关于 Windows 上的远程文件系统。

假设您有工作站 X，它可以访问网络上的文件系统 - 比如说 - \\ServerY\MYDir\。

想象一个场景，你在 X 上有两个并发线程。

1. 线程 1 正在将文件写入 X - 中的本地硬盘目录C:\MYDir\。
2. 线程 2 正在写入\\ServerY\MYDir\.

我想知道这两个IO操作实际上是独立的，即线程1仅使用X的硬盘控制器，线程2仅使用网络并将所有数据在线传递给Server，实际上是写入到硬盘驱动器上服务器Y。

或者

线程 2 是否也在 X 中制作一些本地缓存数据（因此使用 X 上的硬盘控制器）。在这种情况下，线程 2 的 IO 操作可能会干扰线程 1 的操作，从而可能导致性能损失。

基本上-在本地文件和远程文件上并行写入会有什么好处吗？

我的问题特定于 Microsoft Networks 或 NFS 等 Windows 支持的远程文件系统

我们必须构建一个可扩展的大型文件系统。由于 LVM 和 Lustre 都可以提供文件系统大小的动态缩放，我想知道 LVM 与 Lustre 文件系统的相对优缺点。提前致谢。