大索引节点有什么好处吗？ （分机4）

Question

从一些模糊的记忆中，我以为我会“改进”创建 Linux 分区时的默认设置，并将 inode 大小增加到 1024，并且还打开-O bigalloc（“此 ext4 功能启用集群块分配”）。

但现在，我找不到网上引用的这些设置的任何具体好处，而且我发现，在 20% 的磁盘使用率下，我已经使用了 15% 的 inode。

那么我应该简单地重新格式化分区，还是有积极的看法（或用作理由）？例如，对于包含大量文件的目录？

Answer 1

如果您有许多包含大量元数据的文件，则较大的索引节点会很有用。最小的索引节点大小可以容纳经典元数据：权限、时间戳等，以及几个块的地址对于常规文件或短符号链接的目标。更大的索引节点可以存储扩展属性例如访问控制列表和SELinux 上下文。如果 inode 中没有足够的空间来容纳扩展属性，则必须将它们存储在单独的块中，这会使打开文件或读取其元数据的速度变慢。

因此，如果您计划拥有大量的索引节点，则应该使用更大的索引节点大小。扩展属性例如复杂的 ACL，或者如果您使用 SELinux。 SELinux 是更大 inode 的主要动机。

Answer 2

较大的索引节点大小可以提高非常大的文件/目录的性能，但会牺牲磁盘使用率（并且可能会降低小文件的性能）。

如果您觉得 inode 使用率太高，则需要仔细查看每个 inode 的字节数比率。多个 StackExchange 站点上有许多相关的问答。

Answer 3

20% 的磁盘使用率与 15% 的 inode 使用率并不算太糟糕。 20% 的磁盘使用率与 100% 的 inode 使用率将是一个问题。问题是，在 100% 磁盘使用率之前是否会达到 100% inode 使用率。这就是您需要更多索引节点的时候。

这在很大程度上取决于您使用文件系统的方式。例如，如果它是仅保存照片或视频或大小一致的类似文件的分区，则您可能无需担心。

如果您的使用是随机的，并且您将来可能会提取一些内核源代码 tarball，那么您当前的比率可能不会成立......

就性能而言，在正常情况下您可能不会注意到差异，只要您没有突破限制的应用程序，例如 24/7 热的数据库，即使是很小的优化也会带来回报。

Answer 4

每个文件保证至少消耗1 个 inode，如果文件足够大，则消耗更多。理论上，如果您的分区将由大量大文件组成，则需要更少的索引节点。更少的索引节点意味着更多的数据磁盘空间。特定的应用程序是数据库分区，其中数据库将大部分数据保存在几个大文件中（即 Oracle、MySQL 和 innodb）。当你说“bigalloc”时，我想你指的是 中的预设之一/etc/mke2fs.conf，例如 CentOS7 中设置inode_ratio为的“big” 32768？我不确定，但我认为这本质上是“每个索引节点字节数”参数mke2fs的参数。-i如果这些假设正确，则需要重新格式化复制：

每个 inode 的字节数比率越大，创建的 inode 就越少。该值通常不应小于文件系统的块大小，因为在这种情况下，将创建比可以使用的更多的 inode。请注意，文件系统创建后无法更改该比率，因此请谨慎确定该参数的正确值。请注意，调整文件系统大小会更改 inode 数量以维持此比率。