以下信息摘自手册页，我想知道每个索引节点字节数和索引节点大小之间的区别？
-i bytes-per-inode
指定字节/索引节点比率。 mke2fs 为磁盘上的每个 inode 字节空间创建一个 inode。每个 inode 的字节数比率越大，创建的 inode 就越少。该值通常不应小于文件系统的块大小，否则会产生过多的 inode。请注意，创建文件系统后不可能扩展文件系统上的 inode 数量，因此请谨慎决定正确的值该参数的值。
-I inode-size
指定每个 inode 的大小（以字节为单位）。mke2fs 默认创建 256 字节 inode。在2.6.10之后的内核和一些早期的供应商内核中，可以利用大于128字节的inode来存储扩展属性以提高性能。inode-size值必须是大于或等于128的2的幂。inode越大-size 索引节点表将消耗的空间越多，这会减少文件系统中的可用空间，并且还会对性能产生负面影响。存储在大索引节点中的扩展属性在旧内核中不可见，并且此类文件系统将无法使用 2.4 内核安装创建文件系统后无法更改此值。
答案1
好吧，首先，什么是索引节点？在 Unix 世界中，inode 是一种文件条目。目录中的文件名只是索引节点的标签（链接！）。一个 inode 可以在多个位置引用（硬链接！）。
-i 每个 inode 字节数（又名 inode_ratio）
由于某些未知的原因，此参数有时被记录为每个索引节点字节数有时作为索引节点比率。根据文档，这是字节/索引节点比率。当表述为以下任一内容时，大多数人都会有更好的理解（请原谅我的英语）：
- 每 X 字节的存储空间有 1 个索引节点（其中 X 是每个索引节点的字节数）。
- 您可以容纳的最低平均文件大小。
公式（取自mke2fs 源代码）：
inode_count = (blocks_count * blocksize) / inode_ratio
或者甚至简化（假设“分区大小”大致相当于blocks_count * blocksize，我还没有检查分配）：
inode_count = (partition_size_in_bytes) / inode_ratio
注 1：即使您在 FS 创建时 ( mkfs -N ...) 提供了固定数量的 inode，该值也会转换为比率，因此您可以在扩展文件系统大小时容纳更多 inode。
注 2：如果您调整此比率，请确保分配的 inode 明显多于您计划使用的 inode...您确实不想重新格式化您的文件系统。
-I 索引节点大小
这是文件系统将为文件系统可能拥有的每个索引节点分配/保留的字节数。该空间用于存储inode的属性（读索引节点简介）。在 Ext3 中，默认大小为 128。在 Ext4 中，默认大小为 256（用于存储extra_isize为内联扩展属性存储和提供空间）。读Linux：为什么要更改 inode 大小？
注意：为每个分配的 inode 分配 X 字节的 disjkspace，无论是空闲的还是已使用的，其中 X=inode-size。
答案2
bytes-per-inode 确定为该文件系统创建多少个 inode； inode-size 决定了每个 inode 的大小。
如果你打算放，你需要很多 inode地段文件系统上的小文件（和/或大量目录）。
AFAIK，如果你想存储，你实际上只需要大于默认大小 256 字节的 inode扩展属性为您的文件。
psusi 在评论中说这是不正确的。
答案3
极其粗略的文件系统示意图：
|_|__inodes__|_______________________DATA_________________________________|
- 节点比率/每个索引节点字节数= 的 inode 数量数据区域
- 索引节点大小= 中每个 inode 的大小索引节点区域
答案4
我真的很喜欢sjas的答案，它给出了区别的本质。
这只是我自己的扩展（因为我无法评论或投票，只是从这个 stackexchange 开始），我想为自己提供一个答案，以平衡的方式用非技术术语来说明，以便需要在数据量期间做出决定的用户可以理解设置但不一定了解实施背后的所有细节。
角色/对象： - 存储设备中的数据卷 - 卷中的文件 - 存储设备，它们被格式化并提供字节块及其地址 - 存储中文件的位置
操作：通过操作系统在存储中创建/删除/重命名文件和文件夹、文件读取/写入/移动、更改权限等。
N 字节大小的文件需要以“块”（块）的形式创建。尽管从理论上讲，人们可以认为文件可以作为单字节序列进行管理（逻辑上可以），但我们在空间中管理文件所需的只是一个指定的索引，告诉一些文件属性（名称等）以及每个文件的起始位置存储。然而，由于硬件设计的“总线”和“块”方式以及性能考虑，这些“块”具有特定的大小，并且是媒体块大小的倍数（例如 512 字节、4096 字节）并且是由 inodes 层管理，该层告诉下一层有关文件位置的信息，以及当需要查找、加载到内存等时，块如何串在一起。
如果一个人有一大卷纸（卷）并且必须为由页面（字符或信息位）组成的文档设计一个信息存储来存储多页文档，那么需要的是一个索引（用于查找文档），存储空间页面（带有一些简单的页面位置）。在 Unix 排序机制（索引节点）和实际切入页面。 inode-size 是索引条目大小（或多或少） bytes-per-inode 是页大小
更改相关两个设置的效果：
更改 inode-size - 通常不需要更改，坚持使用默认值（根据之前讨论的答案中发布的链接）
每个 inode 的字节数 - 影响可以在卷中创建的最大文件数（可能是性能和未使用字节的“浪费”）
回到纸卷类比：想象一下必须在这样的系统中写入和存储特定尺寸的文档（文件）（或许多不同尺寸的文档） - 如果在“写入和存储系统”期间呈现页面尺寸“定义并不灵活，同一个文档可能需要很多页，如果“系统”页面尺寸非常大而文档尺寸很小，那么可能会因为在一页中留有空白和将小文件放入其中而浪费大量纸张。如果页面尺寸较大 - 文档需要使用的页面较少，但最后使用的页面中可能会存在大量“浪费的空白空间”。所以这一切都取决于......将使用的文件的大小和数量。另一个考虑因素是查找和获取多页文档的速度。
希望它有意义（对我来说），如果我严重滥用了 ext 设计或 mkfs 选项的任何部分，请发表评论。