我们有一个中央存储服务器（PowerEdge R720）为HPC群集提供共享文件，并有两个硬件RAID控制器（PERC H810，每个驱动2个MD1200机箱，装满7200转4TB磁盘）。 与典型的HPC工作负载一样，访问模式预计将是高度并行的顺序读取/写入。 我认为将文件分条到两个arrays将会提供更好的总吞吐量，但是在硬件RAID之上的软件RAID 0的想法听起来很疯狂。
我想出了两个select：
XFS优点：项目配额。
XFS缺点：XFS上的NFSperformance出非常差的元数据性能（如果吞吐量很大，会降低到几乎不可用的程度，我是否调整了错误？）。
光泽优点：显着改善元数据性能。
光泽缺点（？）：我们没有专门的元数据设备，不得不对数组进行分区。 听起来不是一个推荐的做法。
我们考虑元数据性能，因为虽然顺序R / W是主要的工作量，但我们有一些程序可以处理大约40k 1GB的文件。 以交互方式pipe理这些文件确实需要可接受的元数据性能
最后一个问题，在硬件和软件上使用什么条带大小？
我们解决了这个问题：
我们调查了我们用户的所有应用程序，发现它们都在许多文件上运行。 因此，不是许多客户正在访问单个大文件的情况，在这种情况下希望在gluster层面上进行条带化处理; 相反，只是将文件随机分发给砖块，能够提供足够的总吞吐量。
虽然这种设置的元数据性能比光泽性差（大约一半），但是在吞吐量大的时候不会降低性能。 结果是可以接受的。
glusterconfiguration目录的配额，再加上它更容易设置比光泽，因此需要明显less于pipe理的努力。 在我的（粗略的）testing中，这个设置的顺序吞吐量与光泽相当，所以我们决定在元数据性能中交换这个部分以便于pipe理。