适当的 Linux(ubuntu 10.04)FS 类型,用于快速 FS 管理许多小文件和目录

适当的 Linux(ubuntu 10.04)FS 类型,用于快速 FS 管理许多小文件和目录

可能重复:
Linux 的最佳文件系统,可处理数以万计的文件,且不会造成系统 I/O 过载

我有一个 240GB 的图像存储,其中大约有 150 万个条目。这些条目中大约有一半是图像文件(4 到 100kb),另一半是深度嵌套的目录。这些图像中大约有一半是重复的,并且已经相互建立了硬链接。

我正在下载该文件系统的备份并将其放在本地测试服务器上,目的是彻底修改目录布局并测试更改。

通常情况下,我只会将这些图像所在的文件系统设置为 ext4(除非必须,否则不要破坏默认值),但我想知道对于这个特定的用例是否有更好的选择。

我已经研究过 XFS、ext3、ext4 和 btrfs,但没有找到任何可靠的基准测试来证明我应该为这个特定任务选择其中一个。

我还受到 Ubuntu 10.04 上默认可用内核的限制,但如果理由足够充分,我会重新编译。

答案1

一般来说,性能应该是选择文件系统的最后一个选择标准。需要考虑的因素有:

  • 文件系统有多稳定
  • 它是否支持日志记录/崩溃一致性
  • 它如何处理目录中的大量文件
  • fsck 需要多长时间(或者是否需要 fscking)
  • 它是否支持xattrs
  • 它能与 NFS 等兼容吗?
  • 文件系统是否可以调整大小,如果可以,可以在线调整吗
  • 它是否支持尾部包装
  • 是否可以调整以与底层 raid 控制器配合使用

我在数据量相当大环境中大量使用 ext4 和 xfs。我对几乎所有我知道永远不会超过 16TB 的文件系统都使用 ext4(目前,主线内核中的 ext4 支持大于 16TB 的文件系统),但实用程序实际上无法创建它们)。对于非常大的文件系统,ext3 的 fsck 时间过长。xfs 现在非常稳定,但过去曾出现内存泄漏和静默损坏问题。我曾经用它来代替 ext3 来减少 fsck 时间和大于 8TB 的文件系统创建(自从将 -F 标志引入 mkfs.ext3 时修复),但最近在 ~2.6.28 时仍然遇到问题。不过,我要指出的是,在 rhel/centos patched 2.6.18 上我没有遇到任何确认的问题。我仍然觉得 ext4 更可靠一些,并且可以升级到 btrfs,但 xfs 现在肯定很稳定。我对 ext4 fscker 更加有信心。

至于性能,您必须将两者配置为与底层设备的条带大小/步幅相匹配。ext4 允许您设置日志的 iopriority (journal_ioprio),可能需要与日志模式一起使用。xfs 在调整较少的情况下性能优于 ext4,但经过适当设置后,它们非常接近。您确实需要使用 ext4 设置条带/步幅。xfs 更适合处理大量小文件,因为它可以将它们完全打包到 inode 中以节省空间,并且对于某些操作(如删除大型目录树)而言,xfs 的性能明显更好。

我的建议是,除非您需要 > 16TB 支持,否则请尝试使用每个块 (-i 4096) 都创建大量 inode 的 ext4,并将其设置为您的 raid 设备。用您的数据完全填充它,然后查看 fsck 和执行常见操作需要多长时间。仅当您遇到 ext4 的特定问题时才转换为 xfs。

相关内容