我正在组装一个Linux机器，它将充当持续集成构建服务器；我们主要构建Java东西，但我认为这个问题适用于任何编译语言。
我应该使用什么文件系统和配置设置？（例如，我知道我不需要为此花费时间！）构建服务器将花费大量时间读取和写入小文件，并扫描目录以查看哪些文件已被修改。
更新：在这种情况下，数据完整性的优先级较低；它只是一台构建机器……最终的工件将被压缩并存档在其他地方。如果构建机器上的文件系统损坏并丢失所有数据，我们可以擦除并重新映像；构建将继续像以前一样运行。
答案1
使用 ext4fs 作为基本文件系统，并添加一些加速选项，例如
noatime,data=writeback,nobh,barrier=0,commit=300
然后在其上联合挂载一个 tmpfs ramdisk，以便在构建期间写入的文件能够从 ramdisk 中获益。要么更改构建过程以在构建结束时将生成的二进制文件移出 tmpfs，要么在卸载之前将 tmpfs 合并回 ext4fs。
答案2
最快的文件系统？tmpfs 已从可用 RAM 中挂载，并noatime进行了设置。
这只有在您有一个程序来检查构建源树所需的所有内容（因为 tmpfs 文件系统的内容会在您重新启动时消失）并且源和对象适合您可用 RAM 的合理角落（有足够的剩余空间来运行您的编译器和链接器而无需交换）的情况下才可行。也就是说，在速度方面，您无法击败 RAM。
答案3
对于 Michael Dillon 的回答，我可以补充说，你可以用几个选项创建 ext4 文件系统：
mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>
dir_index
Use hashed b-trees to speed up lookups in large directories.
extent
Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead. This is a much more efficient encoding which speeds up filesystem access, especially for large files.
-i 8096为您提供更多的每个大小的 inode，这很有用，因为构建环境会创建大量文件。
答案4
您描述的操作为理想文件系统需要能够做什么提供了一些关键提示：
- 构建过程中出现大量随机 r/w 访问。
- 许多文件需要在短时间内更新，因此快速的元数据操作至关重要。
- 在文件非常繁重的文件系统上有效处理许多小文件。
- 足够成熟，不会在罕见且模糊的边缘情况下冒数据丢失的风险。
Btrfs 和 Ext4 是上述三种文件系统之一，第四种则值得怀疑。Ext4 可能已经足够成熟，但 btrfs 尚未完成。noatime有助于提高元数据操作的效率，但当您创建大量新文件时，您仍然需要元数据操作非常快。
此时底层存储开始成为一个因素。XFS 元数据操作往往集中在几个块中，这可能会给操作带来压力。Ext 样式的文件系统更擅长让元数据更接近其描述的数据。但是，如果您的存储足够抽象（您在 VPS 中运行，或连接到 SAN）没什么大不了的。
每个文件系统都可以通过一些小的加速来获得多几个百分点。底层存储的性能将极大地影响您能看到的增益。
用存储术语来说，如果存储中有足够的 I/O 操作开销，文件系统效率低下就不再那么重要了。如果您使用 SSD 作为构建分区，文件系统的选择就不如您更习惯使用什么更重要。