问题标签 [distributed-filesystem]

我只是在读这个https://en.wikipedia.org/wiki/Clustered_file_system#Distributed_file_systems

DFS 的定义对我来说似乎准确地描述了 Dropbox，但它不在示例列表中，当然如果它是我认为的那样的话。

那么Dropbox有什么不同使它不属于这一类呢？

我们公司有五百万用户。我们存储用户的代码文件。用户可以编辑和添加他们的文件，就像 web IDE，web IDE 列出用户的文件。我们使用 PHP 函数来实现这些操作，例如 readdir、file_get_contents 和 file_put_contents。我们使用了MooseFS，但是当我们读取程序中的文件时，尤其是加载速度很慢。

所以，我们需要更换文件系统，希望有人能给我一些建议，我们有大量的小文件，应该使用哪个分布式文件系统。

当我打开存储在分布式文件系统中另一个节点中的文件并仅读取 100 个字节时。文件系统是否尝试将更多数据“预取”到我的节点？例如，发送文件的网络流量超过 100 字节。

另一个问题是，如果我寻求存储在另一个节点中的文件的末尾。分布式文件系统是否尝试将整个文件发送给我？或者没有网络使用来传输文件，因为只有指向文件中位置的指针发生了变化？

我想从具有分布式文件系统架构的 Windows 网络位置获取类似 ping 的响应，例如

一旦我有了主机，我就可以轻松地 ping 到该位置。

folder_x我可以通过查看 Windows 资源管理器中的 DFS 选项卡来确定主机名，如下所示

如何在 Python 中以编程方式执行此操作？

I have an API which creates a file based on user input. I need to distribute this file over a cluster, such that 1 file should be on 1 node only. Can I use zookeeper to achieve this, and how?

A user may want to delete the file. Which means that zookeeper needs to delete the file from the node, when asked to.

I've read through the zookeeper wiki, but it is difficult to understand how/when to use it.

我一直在尝试优化我的 GlusterFS 存储集群的小文件性能。

许多论坛主题和博客文章似乎建议cluster.readdir-optimize在音量上设置属性，例如：

此选项的默认值（从 GlusterFS v3.10 开始）似乎是off，这让我认为启用此功能必须进行一些权衡。但是，我无法在任何地方找到任何确切解释此选项作用的文档。

在生产中启用此选项之前，我想了解它的功能。

我从Google 文件系统论文中不明白这一点

一个小文件由少量块组成，也许只有一个。如果许多客户端访问同一个文件，存储这些块的块服务器可能会成为热点。

一个小文件有什么不同？许多客户端访问的大文件不是同样可能导致问题吗？

我曾想过/阅读以下内容：-

• 我假设（如果我错了，请纠正我）大文件块存储在不同的块服务器上，从而分配负载。在这种情况下，假设 1000 个客户端从每个块服务器访问文件的 1/100。所以每个 chunkserver 不可避免地会收到 1000 个请求。（与访问单个小文件的 1000 个客户端不同。服务器收到 1000 个小文件请求或 1000 个大文件部分请求）
• 我读了一些关于稀疏文件的内容。小文件根据文件填满一大块或几块。因此，据我了解，不会重建小文件，因此我已将其排除为热点的可能原因。

Flink 有一个 RollingFileSink，根据文档，它可以与 HDFS (Hadoop) 一起使用。是否有类似的类可用于将数据接收到 NFS、ext4 或 GPFS 等文件系统？

https://ci.apache.org/projects/flink/flink-docs-release-1.4/dev/connectors/filesystem_sink.html

Dask 支持哪些分布式文件系统？具体来说，可以从哪些文件系统读取 dask.dataframe 的？从 Dask 文档中，我可以看到肯定支持 HDFS。是否支持任何其他分布式文件系统，例如 Ceph 等？

我可以在这里找到一些关于支持其他文件系统的想法的讨论：https ://github.com/dask/distributed/issues/33但没有最终结论，除了 HDFS 比其他选项“更糟糕”。

感谢您的帮助！

通常，在使用 Hadoop 和 Flink 时，从分布式文件系统打开/读取文件将返回扩展 java.io.InputStream 的 Source（Sink 的对应物）对象。

但是，在 Apache Ignite 中，IgfsSecondaryFileSystem，更具体地说是 IgniteHadoopIgfsSecondaryFileSystem，在调用其“ open ”方法（通过传递 IgfsPath）时返回 HadoopIgfsSecondaryFileSystemPositionedReadable 类型的对象。

HadoopIgfsSecondaryFileSystemPositionedReadable提供了一种“读取”方法，但需要了解有关要读取的数据所在位置的详细信息，例如输入流位置。

如何在调用read方法之前确定这些细节？

我对这些框架很陌生，也许存在一种不同的方法来获取基于指向存储在 Hadoop 文件系统中的文件的 IgfsPath 的 InputStream？

我正在尝试实现此处描述的内容：https ://apacheignite-fs.readme.io/docs/secondary-file-system

提前感谢您的任何提示！