开发人员构build最快的文件系统是什么？

使用ext4fs作为基础文件系统，有一些加速选项

noatime,data=writeback,nobh,barrier=0,commit=300

然后union在上面安装一个tmpfs ramdisk，这样在构build期间写入的文件就可以得到ramdisk的好处。 可以在构build结束时更改生成过程以将生成的二进制文件从tmpfs移出，也可以在卸载之前将tmpfs合并回ext4fs。

最快的文件系统？ tmpfs安装在可用的RAM中，没有设置时间。

如果你有一个程序检查构build你的源代码树所需的一切（因为tmpfs文件系统的内容在你重新启动的时候将会消失），并且如果源代码和对象符合你可用RAM的一个合理angular落有足够的遗留运行你的编译器和链接器，而不需要交换）。 那就是说你不能为了速度而打败RAM。

迈克尔狄龙的答案我可以补充说，你可以创build几个选项的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，因为build筑环境会创build大量文件。

对于源代码来说，最好是具有即时压缩支持，即Reiser4或Btrfs 。 尽pipe我曾经听说过人们使用两个FS都很重，很高兴。 🙂

下一个select（我通常是）是Reiser3 ，而不是Ext3 。 现在Ext3可以更快一些，但是Reiser3没有i-nodes格式的时间限制，支持在线更改“data =”选项。 它有“尾巴”支持允许更紧凑的小文件打包，但如果你关心速度，“notail”它。

XFS和JFS都将是“很多小文件”的情况下的痛苦，特别是如果你需要rm'ing的话。

（忘了提及EXT4：是的，EXT3更快，但是EXT3的所有限制都是EXT4）。

您所描述的操作给出了关于理想文件系统需要能够做什么的一些关键提示：

• 在构build过程中大量随机访问r / w。
• 很多很多文件在短时间内得到更新，如此快速的元数据操作是至关重要的。
• 在可能非常大文件的文件系统上高效地处理许多小文件。
• 已经足够成熟，不会在罕见和模糊的边缘情况下冒险丢失数据。

Btrfs和Ext4是以上三种，第四种是可疑的。 Ext4可能已经足够成熟了，但是Btrfs还没有完成烘焙。 noatime有助于提高元数据操作的效率，但是当你创build一堆新的文件时，你仍然需要元数据操作才能快速。

这是基础存储开始成为一个因素。 XFS元数据操作往往集中在几个块，这可能会导致操作紧张。 Ext风格的文件系统更好地使元数据更接近其描述的数据。 但是，如果您的存储空间足够抽象（您正在运行VPS或连接到SAN） ，则无关紧要 。

每个文件系统几乎没有加速可以完成几个百分点。 底层存储的性能将会大大影响您将看到多less收益。

按照存储的说法，如果存储中有足够的I / O操作开销，那么文件系统效率低下并不重要。 如果您使用固态硬盘作为您的构build分区，则文件系统的select不如您更舒适的工作重要。

对于大量的小文件，我推荐Reiser超过ext3，xfs，jfs …，虽然我听说ext4比以前的这种访问模式更好一些（即与poise所说的相反）。

Reiser将大量的文件结构推向了inode树 – 所以在处理小文件时效果非常好。

然而，领先的文件系统之间的行为差​​异相对较小，相比之下，通过有足够的物理内存caching/缓冲有效地获得的好处。

并扫描目录以查看哪些文件已被修改。

这是一个蹩脚的方式来解决问题 – 即使它相对简单。 如果这是重要的，考虑编写一个inotify处理程序来索引mods。

OTOH，如果你使用闪存固态硬盘（这会给你非常低的寻找时间），我build议使用一个fs分发写寿命更长久的原因 – 例如JFFS2