用于密集型随机I / O的文件系统/选项

要求和约束：

• 50:50读：写比例
• 正在写入的文件的范围将从大于块大小到比块大小大得多。
• 个别请求的范围从128KB到4MB
• 在Linux上
• 文件系统将是非常大的，在14TB。

未知数将有助于：

1. 随机I / O是否在文件中，或者纯粹是基于整个文件以128KB-4MB块读取和写入
2. 文件更新的频率。
3. 并发性：并行读/写操作（I / O操作）的频率。

顺序I / O

如果50:50的比例是通过读取和写入整个文件以及相当大的文件来表示的，那么就文件系统而言，您的访问模式比随机更有序。 使用基于范围的文件系统来提高文件系统的顺序性以获得最佳性能。 由于文件非常大，如果硬件支持（某些RAID控制器提供此function），预读将提供显着的性能提升。

随机I / O

如果您计划同时进行读取/写入操作，则会发生变化，此时它变得非常随机。 如果您打开大量文件并在这些文件中读取/写入小部分，就好像它是数据库一样。

我遇到的最大的误解之一是在处理高度随机的I / O时，碎片整理的文件系统比碎片整理的性能要好。 只有在元数据操作在分散的文件系统上受到很大影响的文件系统中才是如此。 对于非常高级别的碎片，基于程度的文件系统实际上可能比其他types的块pipe理遭受更多的性能下降。

也就是说，当I / O访问模式和速率将磁盘推到最大能力时，这个问题才会变得明显。 在文件系统中有14TB，这意味着在实际的存储arrays中有7到50个主轴，这产生了广泛的能力; 从用于7x 2TB 7.2K RPM驱动器的630 I / O Ops到用于50x 300GB 15K RPM驱动器的9000 I / O Ops。 7.2K RPM RAIDarrays将比I / O饱和速度快15K RPM RAIDarrays。

如果您的I / O操作速度没有推动您的存储限制，那么文件系统的select应该更多地基于整体pipe理的灵活性，而不是调整性能的最后几个百分点。

但是，如果您的I / O实际上正在运行您的存储单元，那么就需要调整。

XFS：

• 安装：将“allocsize”设置为不大于65536（64MB），但将其设置为高。 这提高了文件访问的元数据速度。
• 安装：将“sunit”设置为RAIDarrays的条带大小。 也可以在格式化时间设置。
• 安装：将“swidth”设置为RAIDarrays中的驱动器数量（R5为N-1，R6为N-2）。 也可以在格式化时间设置。
• 格式：如果您确实需要最后一个百分点，请将文件系统日志放在完全独立的存储设备上-l logdev=/dev/sdc3

EXT4：

• 格式： -E stride在RAID中的单个磁盘条-E stride设置块的数量（512B或4K取决于驱动器）。
• 格式： -E stripe-width在XFS中将-E stripe-width设置为“swidth”
• 格式：与XFS一样，通过将日志放置在完全独立的存储设备上，可以将性能的最后百分比排除在外。 -O journal_dev /dev/sdc3/

我认为这里真正的问题不仅仅是文件系统，而是你使用文件系统的参数。 有一件事可能会影响可能是预先读取的大小。

但是，好的，让我们来谈谈名字。 除了XFS之外，我认为ext4将适合您的需要。 底线是，我认为你需要基于范围的文件系统，以尽可能避免碎片。 XFS和ext4都支持延迟写入IIRC，所以两者都可能帮助你增加写入合并的机会。

问候，

穆利阿迪。

考虑到您拥有的数据规模，我想您应该考虑一下networking集群文件系统，比如Lustre，或者IBM专有的GPFS。 这些devise旨在在像您这样的苛刻工作负载下提供高性能的结果。