我工作的集群有一个标记为“快速”的文件系统，没有进一步的解释。但是文件系统类型是“lustre”，这强烈暗示了Lustre文件系统。虽然很容易找到有关此文件系统类型的一般信息，但我无法找到有关如何从中获得最大性能的任何信息，使用程序员可以处理的参数：文件布局和访问模式。有人对此有经验吗？
由于我希望得到“只是运行基准”的回复，这当然是我所做的。我发现读取访问有时比同一台机器上的 NFS 文件系统快得多，但有时明显更慢，尽管我没有看到给出这些极端结果的两个应用程序之间有任何显着差异。这就是为什么我想了解性能问题而不仅仅是数字。
这是一个开放的问题。性能差异是否总是可重现的？在您的一项测试中，其他人可能真的在破坏文件系统。
Lustre 有一些锁定问题，如果您不小心，可能会导致性能问题。我们需要更多地了解文件系统硬件和软件的设置方式，才能开始诊断您的问题。我们还需要更多地了解这两个应用程序及其 I/O 模式。
大概您已经与运行您可以访问的计算机的人进行了交谈，但他们并没有太大的帮助。如果没有，你真的很想先和他们谈谈。
问题是， fast有很多定义。您需要高带宽、低延迟还是两者兼而有之？您是否需要用于离线处理的快速只写存储，或者您是否需要网络上另一台机器上的即时回读功能来处理该数据？您需要访问单个文件还是多个文件？
在我工作的地方，我们将光泽广泛用于一些实验站。我们的集群可以愉快地处理饱和多个千兆以太网链路的图像数据流，但它要求它在一个包含一千个文件的目录中列出一个目录列表，它就会爬行。
由于数据可能分布在许多节点上，并且这些节点积极缓存，如果您正确安排事情，那么您可以让多个系统协作处理数据，并且每个系统都可以比将数据存储在本地更快地访问数据。当然，我们这里的检测器每秒生成的数据比本地磁盘所能承受的还要多。对于这些检测器，流式传输到 luster 集群是唯一现实的选择。
对于我们的设置，似乎 luster 针对高带宽进行了优化 - 快速访问大型连续数据集，但由于单个元数据服务器在任何给定文件系统的所有 luster 节点之间共享，正常的文件系统活动就像ls并且grep真的可以受到打击。这显然不是最新版本的 lustre 的问题，但我还没有看到实际情况。