我计划（私下）部署一台服务器，该服务器将对 100MB 到 50GB 大小的文件进行随机 I/O 操作。请求大小范围为 128 KB 到 4MB。读写比例为 50:50，读取比例略高。
哪种文件系统能够最好地处理这种负载？我目前选择了 XFS。但我应该研究哪些可调参数？
谢谢
答案1
要求和限制：
- 读写比为 50:50
- 正在写入的文件大小将从远大于块大小到大大大于块大小。
- 单个请求大小范围为 128KB 至 4MB
- 在 Linux 上
- 该文件系统将相当大，达到 14TB。
可能有帮助的未知数：
- 随机 I/O 是否发生在文件内，或者是否纯粹基于以 128KB-4MB 块形式读写的整个文件
- 文件更新的频率。
- 并发性：并行读/写操作（I/O 操作）的频率。
顺序 I/O
如果 50:50 的比例表示为读取和写入整个文件，而且是相当大的文件，那么就文件系统而言，您的访问模式是顺序的，而不是随机的。使用基于范围的文件系统来增加文件系统的顺序性，以获得最佳性能。由于文件非常大，如果硬件支持，预读将提供显着的性能提升（某些 RAID 控制器提供此功能）。
随机输入/输出
如果您计划同时执行读/写活动，情况就会发生变化，此时它会变得非常随机。如果您打开大量文件并像数据库一样读取/写入这些文件中的一小部分，情况也是如此。
我遇到的最大误解之一是，在处理高度随机的 I/O 时，经过碎片整理的文件系统比碎片化的文件系统性能更好。这只适用于以下文件系统：元数据操作在碎片化的文件系统上会遭受巨大损失。对于碎片化程度非常高的情况，基于扩展区的文件系统实际上会比其他类型的块管理遭受更多的性能下降。
也就是说，只有当 I/O 访问模式和速率将磁盘推向最大容量时，这个问题才会变得明显。文件系统中有 14TB，这意味着实际存储阵列中有 7 到 50 个主轴，这会产生很大的容量范围；从 7 个 2TB 7.2K RPM 驱动器的 630 I/O 操作到 50 个 300GB 15K RPM 驱动器的 9000 I/O 操作。7.2K RPM RAID 阵列达到 I/O 饱和的速度比 15K RPM RAID 阵列快得多。
如果您的 I/O 操作率没有达到您的存储极限，那么文件系统的选择应该更多地基于整体管理灵活性，而不是调整性能的最后几个百分点。
然而，如果您的 I/O 确实正在全力运行您的存储，那么就需要进行调整。
XFS：
- 安装：将“allocsize”设置为不大于 65536（64MB），但请将其设置得较大。这可提高文件访问的元数据速度。
- 安装：将“sunit”设置为 RAID 阵列的条带大小。也可以在格式化时设置。
- 安装：将“swidth”设置为 RAID 阵列中的驱动器数量（对于 R5，则为 N-1；对于 R6，则为 N-2）。也可以在格式化时设置。
- 格式：如果你真的需要最后一个百分点，那么把文件系统日志放在一个完全独立的存储设备上
-l logdev=/dev/sdc3
外部4：
- 格式：
-E stride设置为 RAID 中单个磁盘条带上的块数（根据驱动器，为 512b 或 4K）。 - 格式：
-E stripe-width在 XFS 中设置为“swidth” - 格式：与 XFS 一样，可以通过将日志放在完全独立的存储设备上来挤出性能的最后一个百分点。
-O journal_dev /dev/sdc3/
答案2
我认为这里真正的问题不仅仅是文件系统，还有你对文件系统使用的参数设置。可能影响的一个因素可能是预读大小。
但是，好吧，我们只讨论名称。除了 XFS，我认为 ext4 也适合您的需求。最重要的是，我认为您需要基于扩展的文件系统来尽可能避免碎片化。XFS 和 ext4 都支持延迟写入 IIRC，因此两者都可能帮助您增加进行写入合并的机会。
问候，
穆利亚迪。
答案3
考虑到您拥有的数据规模，我认为您需要考虑网络集群文件系统，例如 Lustre 或 IBM 专有的 GPFS。这些文件系统旨在在像您这样的苛刻工作负载下提供高性能结果。