对于我不关心数据是否在崩溃或断电后还能保留的驱动器，例如 /tmp，最快的文件系统（和/或文件系统选项）是什么？
数据有几百 GB，所以不可能全部装入 RAM。其中既有小文件，也有大文件（比如 HTML 文件和视频）。
最好是创建一个大型交换分区并使用 tmpfs 吗？（这有用吗？）还是我应该使用 ext2/3/4 或 XFS 或 Btrfs？我应该使用哪些优化选项来关闭所有安全功能并从文件系统中获得最佳性能？
磁盘是 HDD。SSD 不可行：这是构建服务器，因此数据总是被删除和重新创建，因此每天写入的字节数是磁盘大小的几倍。这意味着消费级 SSD 不太可能持续使用，而为高写入负载设计的数据中心级 SSD 太贵了。
答案1
听起来你的构建相当大，所以我会远离大规模交换+tmpfs - 这可能会在构建时不加区分地迫使你的系统进行交换，从而破坏你的构建性能。
对于我的构建系统，我只有 ext2 和 ext3 选项，ext2 更快（可以理解 - 没有日志记录）。
另请参阅tune2fs和山除了文件系统选项（如适用）。你可能会放弃类似用户属性，访问控制列表。 你可能能够删除时间戳（诺亚泰，诺迪拉蒂梅），但要小心 - 一些构建可能依赖于此。
别忘了碎片，碎片在这种高度混乱的分区中确实会悄然出现，尤其是当它们的填充水平经常超过 80-90% 时。我大约每月重新格式化一次构建分区 - 仅就我的构建而言，这就意味着 10-15% 的改进。
我认为解决这个问题的最好方法是真正尝试你的选择，测量和比较使用你的典型构建作为参考。
附注：硬盘的速度可能不是影响整体构建速度的重大限制因素（我曾尝试过在 tmpfs/ramfs 上与在 HDD 上相比改进不到 10%）。构建结构/依赖性/并行性（可能随着代码的发展而改变）、-j 因子、CPU/RAM 负载、网络、构建可能使用的其他基础设施服务也很重要。
答案2
我不想成为那样的人，但...这取决于情况。这完全取决于你的工作量。只有测试才能显示最佳选择。如果这是构建服务器，你的 CPU 可能会受到限制，所以我会选择最简单的解决方案。
使用 tmpfs/swap 会在数据从内存中推送和提取时对 CPU 造成巨大负担。我不会选择这种方式，因为如果这是构建服务器，您可能希望这些周期用于构建。
在文件系统类型方面，我会选择任何文件系统并使用“noatime”安装它。这将以最少的工作量提供最佳性能，以开始一些测试。