如何减少 ext4 文件系统上的 inode 利用率？

Question

我的需求摘要

我们将大量文件放在文件系统上，以便日后进行分析。我们无法控制将拥有多少文件，而这个盒子需要访问所有文件。

无法改变的限制

1. 我无法更改 inode 限制。它是 ext4，默认为 40 亿左右
2. 文件总是很多。问题不在于如何减少文件数量，而在于如何绕过 40 亿 inode 限制。
3. 我无法使用网络存储。此设备位于数据中心，由于现有数据吞吐量惊人，因此无法使用网络存储。

我的想法

1. 我可以将文件作为环回设备安装到我们放置这些文件的位置。
   • 优点：易于实现
   • 缺点：另一层复杂性，但相当薄弱。
2. XFS. 无 inode 限制。
   • 优点：这显然只是消除了问题。
   • 缺点：不确定对生产系统进行这一改变能有多大的灵活性。

我的问题

还有哪些其他策略可以规避这一硬性限制？我提到的方法还有其他优点/缺点吗？

Answer 1

我建议你使用一个文件系统专门用于处理你的需求的网络服务器。首先想到的是支持 zfs 的东西（freenas 和 nexenta，尽管后者的免费版本有一些限制），或者如果你能负担得起，你可以买一些像 netapp 这样的产品。

我不太熟悉 freebsd 等平台上的 UFS，但听说它也能用。

Answer 2

我们缺少的信息...

• Linux 的发行版和版本。
• 磁盘布局（磁盘托架、RAID 控制器等）。

ext4 听起来不像是你想要的。所以不要使用它...

XFS 应该能很好地处理你的情况。它位于 Linux 内核中，但部署在很大程度上取决于你的磁盘灵活性。还有一些XFS 可调参数这将有助于您的负载……开箱即用，它运行得不是特别好。您需要正确的文件系统创建和挂载选项其余的取决于你的发行版，无论你使用的是控制器以及您的具体工作量。

Answer 3

我想你已经回答了自己的问题，XFS 选项似乎是最好的（我猜你甚至会获得性能提升）。更复杂的部分应该是，如何将 EXT3/4 转换为 XFS？

如果您的存储不是唯一的物理 RAID VD（并且您没有在 BlockDevice 上创建 fs 直接 - mkfs.ext4 /dev/sdb），那么我建议您将 fs 树划分为更小的块并相应地安装它们，配置您的软件以同时写入两个位置，并在可能的情况下拆分写入。例如。

• /alotofsmallfiles/part1->/dev/ext4fs1
• /alotofsmallfiles/part2->/dev/ext4fs2

如果无法从应用程序中拆分写入，您可以创建一个 cron，每隔一段时间将文件从 ext4 分区移动到新的 XFSn分钟

Answer 4

其他选项：

• 根据需要创建文件系统。使用 LVM 进行分区，而不是将文件系统直接附加到 MBR。您可以在树中的任何位置安装 FS，因此您可以随时随地添加新文件系统。此外，如果您愿意，LVM 可以跨越多个磁盘的部分，这意味着物理介质边界不再那么重要。

• 环回文件系统 (FS) 不是糟糕的这个想法，但实际上为什么不使用 LVM 呢？全是优点，没有缺点。

• 如果您只是存档文件（即非随机访问），那么直接将它们保存到 .tar.gz 文件中并不是一个坏主意。我还看到过这样的系统，在构建结构时，文件会暂时“暂存”到 SSD 中，然后转储到旋转驱动器上的 tar.gz 中进行长期存储。

• XFS 不是一个糟糕的选择，尽管它也有自己的缺点。例如，它对非正常关机的容忍度就不那么高。虽然你不会想到会有数据丢失，但有时确实需要更多的手动干预。

在所有这些方法中，我最喜欢的是将文件自动推送到 .tar.gz 档案中。它可以节省空间和 inode，而且非常整洁。大量小文件会使文件系统的性能远低于预期。